С.Д. Кузнецов - Основы баз данных (1121716), страница 32
Текст из файла (страница 32)
Правильно спроектированные, хорошо нормализованные реляционные базы данных помогают решению корпоративных проблем. Да, любое правильно развивающееся предприятие рано или поздно приходит к использованию систем категории ОЕАР например, некоторой разновидности систем поддержки принятия решений (Пес)гйоп Яиррогг Яумет — ОЯЯ). В базах данных таких систем обновления очень редки, а запросы могут иметь произвольную сложность, включая соединения многих отношений, Но, во-первых, технологически правильно для системы ОЕАР поддерживать отдельную базу данных (обычно подобные базы данных называют храннлищами данных — Эагайбгелоизе), а во-вторых, основными источниками данных для построения таких хранилищ данных являются базы данных систем ОЕТР. Так что актуальность правильно спроектированных баз данных ОЕТР-систем не уменьшается, а постоянно возрастает.
Следует ли из этого, что принципы нормализации непригодны для проектирования баз данных ОЕАР-приложений? И снова в ответ категорическое НЕТ! Возможно, окончательная схема такой базы данных должна быть денормализована из соображений повышения эффективности выполнения запросов. Но чтобы получить правильную денормализованную схему, нужно сначала понять, как выглядит нормализованная схема.
Основной вывод этой и предыдущей лекций можно сформулировать следующим образом. Пока мы остаемся в мире реляционных баз данных, для правильного проектирования базы данных необходимо понимать принципы нормализации, воспринимая их не как догму, а как руководство к действию, Кстати, это относится не только к «ручному» проектированию реляционных баз данных, но и к их проектированию с применением семантических моделей данных и САЯЕ-средств, которые мы обсудим в следующих двух лекциях. Лекция 9 Ей-диаграммы Лекция 9. Проектирование реляционных баз данных с использованием семантических моделей: Ей-диаграммы В этой н следующей лекциях обсуждакпся подходы к проектированию реляционных баз данных на основе использования семантических моделей данных.
Лекции обеспечивают начальный уровень знаний в этой области и не заменяют книг, целиком посвященных данной теме. Настоящая лекция посвящена общему введению в семантические модели данных и краткому рассмотрению диаграммной семантической модели «Сущность-Связь». Анализируются стандартные приемы преобразования концептуальной схемы базы данных, представленной в терминах ЕК-модели, в реляционную схему. Квючевые слова: семантическая модель данных, концептуальная схема базы, системы автоматизации проектирования баз данных, семантическая модель еп111у-ке!а11опзыр (сущность-связь), сущность, тип сущности, экземпляр типа сущности, связь, тип связи, экземпляр типа связи, бинарная связь, рекурсивная связь, конец связи, роль связи, степень конца связи, обязательность связи, атрибут сущности, уникальный идентификатор типа сущности, нормальные формы ЕК-диаграмм, первая нормальная форма ЕК-диаграммы, вторая нормальная форма ЕК-диаграммы, третья нормальная форма ЕК-диаграммы, подтипы и супертипы сущностей, уточняемые степени связи, взаимно исключающие связи, каскадные удаления экземпляров сущностей, получение реляционной схемы из ЕК-диаграммы, представление в реляционной схеме супертипов и подтипов сущности, представление в реляционной схеме взаимно исключающих связей.
Введение Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования разнообразных предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе кратко рассмотренного нами в двух предыдуших лекциях механизма нормализации часто представляет собой очень сложный и неудобный для проектировщика процесс.
155 Курс Основы баэ данных Ограниченность реляционной модели при проектировании баз данных При использовании в проектировании ограниченность реляционной модели проявляется в следующих аспектах. ° Модель ие обеспечивает достаточных средств для представления с мысла данных. Семантика реальной предметной области должна независимым от модели способом прелставляться в голове проектировщика. В частности, это относится к отмечавшейся нами ранее проблеме представления ограничений целостности, выходящих за пределы ограничений первичного и внешнего ключа. ° Во многих прикладных областях трудно моделировать предметную область на основе плоских таблиц*. В ряде случаев иа самой начальной стадии проектирования дизайнеру приходится нелегко, поскольку от него требуется описать предметную область в виде одной (возможно, даже ненормализованной) таблицы.
е Хотя весь процесс проектирования происходит иа основе учета зависимостей, реляционная модель ие предоставляет какие-либо формализованные средства для представления этих зависимостей. ° Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области (есущиостей») и выявления связей между этими сущностями, реляционная модель данных ие предлагает какого-либо механизма для разделения сущностей и связей*'. Семантические модели данных Потребность проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области вызвала к жизни направление семантических моделей данных.
Хотя любая развитая семантическая модель данных, как и реляционная модель, включает структурную, маиипуляциоииую и целостную части, главным назначением семантических моделей является обеспечение возможности выражения семантики данных. ' Начиная с этой лекции, мы переходим к использованию терминов таблица, строка и столбец вместо строгих реляционных терминов оешошецие, атрибут и таблица, поскольку здесь пол реляционными» базами ланных понимаются, главным образом, Я)ь-ориентированные базы данных, для которых эта упрощенная терминология более естественна.
" Многие сторонники реляционного подхола считают отсутствие раиельного прелставления сущностей и связей преимуществом реляпионной мололи данньш, мотивируя это тем, что зачастую то, что вчера считалось сущностью, сегодня разумнее принять за связь, и наоборот. Это, безусловно, верно с точки зрения поддержки и молификаггии существующих реляционных баз ленных, но отнюдь не так с точки зрения проектирования базы ланных. 15б Лекция 9 ЕП-диаграммы Прежде чем мы коротко рассмотрим особенности двух распространенных семантических моделей, остановимся на возможных областях их применения. Чаще всего на практике семантическое моделирование используется на первой стадии проектирования базы данных.
При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования. Основным достоинством данного подхода является отсутствие потребности в дополнительных программных средствах, поддерживающих семантическое моделирование. Требуется только знание основ выбранной семантической модели и правил преобразования концептуальной схемы в реляционную схему.
Следует заметить, что многие начинающие проектировщики баз данных недооценивают важность семантического моделирования вручную. Зачастую это воспринимается как дополнительная и излишняя работа. Эта точка зрения абсолютно неверна. Во-первых, построение мощной и наглядной концептуальной схемы БД позволяет более полно оценить специфику моделируемой предметной области и избежать возможных ошибок на стадии проектирования схемы реляционной БД. Во-вторых, на этапе семантического моделирования производится важная документация (хотя бы в виде вручную нарисованных диаграмм и комментариев к ним), которая может оказаться очень полезной не только при проектировании схемы реляционной БД, но и при эксплуатации, сопровождении и развитии уже заполненной БД.
Неоднократно приходилось и приходится наблюдать ситуации, в которых отсутствие такого рода документации существенно затрудняет внесение даже небольших изменений в схему существующей реляционной БД. Конечно, это относится к случаям, когда проектируемая БД содержит не слишком малое число таблиц. Скорее всего, без семантического моделирования можно обойтись, если число таблиц не превышает десяти, но оно совершенно необходимо, если БД включает более сотни таблиц. Для справедливости заметим, что процедура создания концептуальной схемы вручную с ее последующим преобразованием в реляционную схему БД затруднительна в случае больших БД (содержащих несколько сотен таблиц).
Причины, по всей видимости, не требуют пояснений. История систем автоматизации проектирования баз данных (САБЕ-средства) началась с автоматизации процесса рисования диа- * Позволю себе одно терминологическое замечание, которое может показаться несколько наивным для специалистов в области инженерии программного обеспечения (аоямага спрпесппй), к числу которых я нс принадлежу. Издавна сугдествует отдельный класс программных систем, предназначепньм для автоматизации проектирования новых продуктов щу Основы баз данных Курс грамм, проверки их формальной корректности, обеспечения средств долговременного хранения диаграмм и другой проектной документации. Конечно, компьютерная поддержка работы с диаграммами для проектировшика БД очень полезна. Наличие электронного архива проектной документации помогает при эксплуатации„администрировании и сопровождении базы данных. Но система, которая ограничивается поддержкой рисования диаграмм, проверкой их корректности и хранением, напоминает текстовый редактор, поддерживающий ввод, редактирование и проверку синтаксической корректности конструкций некоторого языка программирования, но существующий отдельно от компилятора.
Кажется естественным желание расширить такой редактор функциями компилятора, и это действительно возможно, поскольку известна техника компиляции конструкций языка программирования в коды целевого компьютера. Но коль скоро имеется четкая методика преобразования концептуальной схемы БД в реляционную схему, то почему бы не выполнить программную реализацию соответствующего «компилятора» и не включить ее в состав системы проектирования баз данных? Эта идея, естественно, показалась разумной производителям САЯЕ- средств проектирования БД.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
