YourLib.net
Твоя библиотека
Главная arrow Базы данных. Проектирование и создание (С.М. Диго) arrow 3.4.3. Дополнительные рекомендации по проектированию БД
3.4.3. Дополнительные рекомендации по проектированию БД

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

   Реляционная база данных, полученная в результате использования предложенного выше алгоритма проектирования, будет являться нормализованной и автоматически находится в четвертой нормальной форме.
   В принципе, вся предметная область может быть представлена в виде одного универсального отношения. Недостатки такого способа хранения известны, и нормализация отношений служит их устранению. Нормализация выполняется путем вертикального разбиения (проекции) исходного отношения.
   Однако хранение нормализованных файлов в свою очередь может привести к отрицательным последствиям, например к замедлению выполнения некоторых операций. Поэтому в некоторых случаях сознательно идут на денормализацию отношений.
   Нормализованные отношения в свою очередь могут быть подвергнуты вертикальному разбиению, например в случае если информация, хранящаяся в одном отношении, редко обрабатывается совместно или если ограничения СУБД не позволяют хранить все атрибуты в одном отношении. Вопросы вертикального разбиения нормализованных отношений выходят за рамки теории нормализации, но их часто приходится рассматривать в реальной практике проектирования ИС. Также за рамками теории нормализации остаются вопросы горизонтального разбиения отношений.
   На решение вопросов о необходимости и степени вертикального и горизонтального разбиения отношений оказывают влияние много факторов, и не только напрямую связанные с оценкой структуры данных (объем занимаемой памяти, степень дублирования данных), но и с затратами времени на выполнение операций разного типа, а также корректностью получаемого при этом результата.
   Горизонтальное разбиение, в принципе, может давать как непересекающиеся, так и пересекающиеся множества. При получении непересекающихся множеств степень дублирования данных не изменится и объем памяти, занимаемый под данные, останется таким же, как и до расщепления. Однако общий объем памяти, требуемый для хранения БД, возрастет. Это произойдет за счет большего объема служебной информации (каждое отношение должно быть самостоятельно описано), а также за счет неиспользованного свободного места в конце каждого физического блока (сектора). Кроме того, возрастет сложность базы данных (одним из показателей которой является число информационных единиц в структуре БД) и сложность обработки. При пересекающихся множествах, кроме того, возрастет степень дублирования данных и возникнут проблемы с поддержанием целостности данных.
   Несмотря на очевидные недостатки горизонтального разбиения, к такому приему достаточно часто прибегают в практике проектирования. Чем это бывает вызвано? Во- первых, горизонтальное разбиение может обеспечить сокращение времени обработки данных, в том числе и за счет распараллеливания выполнения операций. Так, выполнение операций селекции, проекции над горизонтальными сечениями эквивалентны выполнению этих операций над всем отношением и могут выполняться параллельно. При этом общее требуемое время выполнения запроса будет меньше, чем t/p (где t - время выполнения запроса над всем отношением, p - число доступных процессоров), так как время еще может сократиться и за счет работы с более короткими файлами. Однако не все операции можно непосредственно выполнить над горизонтальными сечениями отношений. Рассмотрим следующий пример. Пусть в БД учебного института хранится информация о студентах. Основным потребителем этой информации являются деканаты соответствующих факультетов. Информация чаще всего обрабатывается и анализируется в пределах факультетов. В этом случае целесообразно сделать горизонтальные сечения и хранить данные в разрезе каждого факультета отдельно. Однако, если вам, например, потребуется получить средний балл успеваемости всех студентов в последнюю сессию, то вам либо придется объединить соответствующие файлы, либо использовать достаточно сложный алгоритм вычисления требуемого показателя.
   Горизонтальное разбиение отношения может производиться по разным принципам. В качестве условия разбиения может использоваться значение какого-либо атрибута (как, например, в рассмотренном выше примере - значение атрибута ФАКУЛЬТЕТ). Довольно часто используется разбиение по временному признаку, например данные за каждый месяц хранятся в отдельном файле. Могут использоваться и другие принципы разбиения: по достижению определенного объема файла, по активности записей и др.

   На это стоит обратить внимание
   1. На построение логической модели базы данных оказывает влияние множество факторов и все они в комплексе должны быть учтены при создании даталогической модели.
   2. Подход к проектированию логической структуры базы данных, рассмотренный для реляционной модели, может быть применен и при проектировании других структу- рированных баз данных. При этом в алгоритме перехода от ER-модели к модели, поддерживаемой конкретной СУБД, должны быть учтены особенности модели данных целевой СУБД.
   3. Так как базовая ER-модель является объектной по своей сути, то она может быть использована и при создании объектных баз данных.
   4. Использование CASE-средств позволяет улучшить качество создаваемых проектов, а при создании крупных корпоративных систем является практически неизбежным.
   5. Использование CASE-средств не освобождает проектировщика от понимания не только общей сущности, но и деталей даталогического проектирования.

Контрольные вопросы

   1. Что называется даталогическим проектированием?
   2. Какая информация является исходной для даталогического проектирования?
   3. В чем заключается проектирование логической структуры базы данных для каждого из известных Вам классов СУБД или конкретных СУБД?
   4. Какие критерии используются для оценки спроектированной базы данных?
   5. В каких случаях и для обеспечения каких целей вводятся искусственные идентификаторы?
   6. Как отображается простой объект и его единичные свойства в реляционной базе данных? в других известных вам СУБД?
   7. Как отображаются условные свойства объектов в реляционной базе данных? в других известных вам СУБД?
   8. Как отображаются множественные свойства объектов в реляционной базе данных? в других известных вам СУБД?
   9. Как отображается отношение типа 1:1 между объектами в реляционной базе данных? в других известных вам СУБД? Влияет ли при этом класс принадлежности объектов на число требуемых файлов/таблиц?
   10. Как отображается отношение типа 1:М между объектами в реляционной базе данных? в других известных вам СУБД? Влияет ли при этом класс принадлежности объектов на число требуемых файлов/таблиц?
   11. Как отображается отношение типа М:М между объектами в реляционной базе данных? в других известных вам СУБД? Влияет ли при этом класс принадлежности объектов на число требуемых файлов/таблиц?
   12. Как отображается в реляционной модели составной объект? в других известных вам СУБД?
   13. Как отображается в реляционной модели обобщенный объект?
   14. Как отображается в реляционной модели агрегированный объект?
   15. Все ли показатели, отображенные в инфологической модели, должны включаться в базу данных?
   16. Какие факторы влияют на принятие решения о том, какие показатели следует хранить в базе данных?
   17. В каком случае надо производить вертикальное и горизонтальное разбиение файлов/таблиц базы данных?

 
< Пред.   След. >