Сравнение концептуального и реляционного моделирования

Чем сложнее модель базы данных, тем труднее разобраться в ней и правильно спроектировать. Эта сложность растет с добавлением объектных множеств, конкретизаций, составных объектов и отношений. В результате проектирования важно, чтобы структура базы данных была логичной и не имела изъянов. Графический подход значительно повышает вероятность получения точных моделей по сравнению с текстовым подходом реляционного моделирования.

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

Зачем нужно преобразование концептуальной модели в реляционную схему базы данных? В настоящее время большинство СУБД основано на реляционной (или более ранней) модели. Объектно-ориентированные СУБД, которые могли бы напрямую реализовать концептуальную схему, еще не достигли «промышленной мощности», необходимой для больших приложений. Кроме того, для простой базы данных напрямую создать реляционную модель не сложнее, чем создать концептуальную модель. Следовательно, оба подхода вполне жизнеспособны и могут адекватно использоваться.

Типы данных

Для окончательного описания модели необходимо завершить описание каждого атрибута в базе данных. Например, в Visual FoxPro определены следующие типы данных:

· Character – символьное выражение до 254 символов (в дальнейшем будем обозначать C(n), где n – число символов).

· Currency – денежное выражение для числовой величины (Y).

· Date – выражение для даты (D).

· DateTime – выражение дата и время (Т).

· Logical – булево выражение.T. или.F. (L).

· Numeric – числовое выражение (N(n, d), где n – общее число знаков, d – число знаков после запятой).

· Integer – целое число (I).

· General – поле для ссылки на объект OLE (G).

· Memo – поле примечаний.

Словарь данных

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

· Допускаются длинные имена таблиц и полей.

· Каждому полю в таблице можно давать комментарии.

· Для полей, помимо идентификаторов, имеются заголовки.

· Введены значения по умолчанию.

· Предусмотрены правила проверки для полей и записей при изменении и вводе новых данных.

· Имеются триггеры для поддержания целостности данных.

· Могут устанавливаться постоянные связи между таблицами, размещенными в базе данных.

· Имеются процедуры для описания сложных условий правил проверки.

· Могут храниться определения для соединений с внешними источниками данных.

· Поддерживаются локальные и внешние представления.

Информация в словаре данных называется метаданными, то есть «данными о данных».

После получения реляционной схемы данных и определения типов атрибутов (полей) таблиц необходимо определить словарь данных.

ВЫБОР СУБД

АНАЛИЗ ИНФОРМАЦИОННЫХ ПОТРЕБНОСТЕЙ МЕНЕДЖМЕНТА. Для различных фирм необходимая информация менеджмента (информация, поддерживающая операции компании и принятие решений) может заметно отличаться. Информационные потребности могут существенно влиять на выбор СУБД. Среди характеристик информации менеджмента, которые могут отразиться на выборе СУБД, можно отметить следующие:

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

· Число приложений, в которых отношения между данными четко установлены и мало подвержены изменениям.

· Текущий и ожидаемый объем вводимой и удаляемой информации.

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

ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРИЛОЖЕНИЯМ. Пользователи приложений делятся на две категории: постоянные и случайные пользователи.

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

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

ПОДДЕРЖАНИЕ НЕПРОТИВОРЕЧИВОСТИ ДАННЫХ. Часто необходимо совместно использовать данные многими приложениями. В таких случаях возможна противоречивость данных. Хорошая СУБД не может гарантировать, что противоречия в данных никогда не возникнут, но она должна обеспечивать средства минимизации частоты их появления. Следовательно, любая оценка СУБД должна включать рассмотрение средств, обеспечивающих согласованность разных копий одних и тех же данных.

ТРЕБОВАНИЯ К ВРЕМЕНИ ОТКЛИКА. СУБД должна обладать необходимым быстродействием, чтобы представлять ценность для пользователей.

ФУНКЦИИ И ВОЗМОЖНОСТИ СУБД. Для того, чтобы оценить способность СУБД удовлетворять информационные потребности фирмы, необходимо рассмотреть выполняемые ею функции и лежащие в их основе свойства.

Эффективная СУБД позволяет расширять и изменять базу данных без потери целостности данных. Активный словарь данных помогает выполнять эту задачу, позволяя поддерживать определения данных отдельно от самих данных.

Для обеспечения защиты и целостности данных при выборе СУБД необходимо обращать внимание на следующие возможности:

· Контроль доступа – важный фактор, позволяющий избежать несанкционированного доступа к данным.

· Контроль параллельной обработки – средства поддержания целостности данных при многопользовательском режиме работы.

· Управление представлениями данных – автоматические средства ограничения данных таблицы, к которым пользователь имеет право обращаться.

· Средства шифровки могут иметь большое значение для организаций, обладающих очень уязвимыми данными.

· Средства резервного копирования и восстановления очень важны для эффективного функционирования системы базы данных.

ВОЗМОЖНОСТИ ЗАПРОСОВ, МАНИПУЛЯЦИИ ДАННЫМИ И СОЗДАНИЯ ОТЧЕТОВ. Способность СУБД легко формировать необходимые отчеты, запросы пользователей, обеспечивать потребности в манипуляции данными – важнейшие характеристики современных СУБД. Хорошая СУБД должна обеспечивать возможность создания структурированных отчетов во множестве различных форматов. СУБД должна поддерживать язык запросов, обладающий большими возможностями, но являющийся простым в изучении и применении.

ПОДДЕРЖКА СОЗДАНИЯ СПЕЦИАЛЬНЫХ ПРОГРАММ. Заслуживающая внимание СУБД должна содержать базовый язык для создания пользовательских приложений или же обеспечивать взаимодействие с одним или более процедурными языками. Многие современные СУБД могут обеспечивать дополнительными возможностями быстрого создания приложений (визуальные методы проектирования, мастера, построители).

ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ. Очевидно, что для установки СУБД на компьютере к отдельным его устройства (например, оперативной памяти, накопителю на жестком магнитном диске) могут быть предъявлены особые требования.

МОДЕЛИ ОЦЕНКИ. Существуют формальные методы оценки СУБД. Одним из таких методов является модель, основанная на выставлении баллов. Эта модель широко применяется на практике. При сравнении различных СУБД выбираются две категории свойств: обязательные и желательные свойства. Проверка обязательных свойств не должна основываться на субъективных суждениях или мнениях. Желательные требования могут включать свойства, которые сложнее измерить. Каждому требованию приписывается весовой коэффициент ki. При этом больший вес соответствует большей степени желательности. Каждому свойству j-й СУБД выставляется балл Bij. Далее для каждой СУБД определяется сумма баллов по формуле:

, где n – число анализируемых свойств СУБД.

Выбирается СУБД, набравшая максимальную сумму Sj.




double arrow
Сейчас читают про: