Критерии оценки БД

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ N 27.

Языки запросов. Общая характеристика.

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

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

2. Полнота - возможность удовлетворения существующих и но­вых потребностей пользователей. Использование подхода «от пред­метной области» к проектированию баз данных и сама идеология бан­ков данных как интегрированного взаимоувязанного хранилища дан­ных способствуют обеспечению этого критерия. Хранение в БД детализированных показателей также повышает возможности удов­летворения разнообразных (в том числе и нерегламентированных) по­требностей пользователей. Полнота является одним из проявлений адекватности БД.

3. Адаптируемость.

3.1. Адаптируемость к изменениям в предметной области.

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

С рассматриваемым критерием будет тесно связан критерий затрат на поддержание системы в работоспособном состоянии. С затратами на адаптацию структуры БД будут непосредственно связаны и затраты на адаптацию прикладного программного обес­печения.

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

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

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

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

3.2. Адаптация к изменениям информационных потребностей пользователей, возможность удовлетворения нерегламентированных запросов. Например, если хранить в БД детальные данные, то любые производные данные можно получить при возникновении необходи­мости в них; если же хранить только какие-либо сводные данные, но не хранить исходные, то получить информацию, отличную от храни­мой, в большинстве случаев нельзя.

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

Одним из проявлений рассматриваемого свойства является мас­штабируемость. Ведущие разработчики программных продуктов уде­ляют большое внимание обеспечению этих свойств.

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

5. Сложность структуры БД. Речь может идти как о сложности самой поддерживаемой в данной СУБД модели данных, так и о слож­ности логической структуры конкретной спроектированной БД.

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

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

Критерий «сложность» никогда не рассматривается как самосто­ятельный.

6. Степень дублирования данных в БД. Различают необходимое, контролируемое и неконтролируемое дублирование. Но какими бы причинами ни было вызвано дублирование данных, оно всегда ведет к необходимости поддержки идентичности всех копий дублируемых значений, росту требуемого объема памяти, повышению трудоемкос­ти корректировки, увеличению числа полей в БД, что повышает ее сложность.

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

8. Объем требуемой памяти. В связи со значительным ростом технических характеристик накопителей и снижением стоимости хра­нения единицы информации значимость данного фактора постоянно снижается. Исходными данными для определения требуемого объе­ма памяти являются: число объектов отображаемой предметной об­ласти, особенности выбранной логической и физической структуры БД, особенности носителя данных. Некоторые CASE-средства вклю­чают в себя блоки оценки объемов памяти.

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

Рассматриваемый критерий особенно важен для систем, работа­ющих в реальном масштабе времени и в интерактивном режиме.

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

2. Стандарты SQL.

Начиная с 1986 года, комитеты ISO (International Organization for Standardization) и ANSI (American National Standards Institute) приступили к созданию ряда стандартов языка SQL, которые впоследствии были приняты и получили следующие названия: SQL86, SQL89, SQL92 и SQL99.

Стандарт SQL86 зафиксировал минимальный стандартный синтаксис языка SQL.

Стандарт SQL89 был принят в 1989 году. Он вводил набор операторов языка SQL, которые должны были реализовывать все СУБД, заявляющие поддержку стандарта SQL89. На практике каждая реальная коммерческая СУБД предоставляет значительно более широкий набор возможностей, чем предусмотрено стандартом. Так, несмотря на то, что большинство СУБД на момент принятия стандарта уже поддерживали встроенный и динамический SQL, в стандарте SQL89 правила встраивания языка SQL в процедурный язык программирования (такой как язык С) и правила использования динамического SQL прописаны не были.

До последнего времени большинство СУБД поддерживали стандарт SQL92.

В стандарте SQL92 было определено три уровня соответствия:

• основной (Entry);
• средний (Intermediate);
• полный (Full).

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

Новый стандарт SQL99, при разработке именовавшийся как SQL3, стандартизировал объектные расширения языка SQL и некоторые процедурные расширения языка SQL. К моменту принятия этого стандарта большинство коммерческих СУБД, таких как Oracle, уже де-факто ввели использование объектных типов и наследования.

В стандарте SQL99 определено обязательное функциональное ядро (Core) и набор уровней расширенного соответствия. Функциональное ядро SQL99 включает в себя основной уровень соответствия SQL92. Уровни расширенного соответствия не являются обязательными для реализации в СУБД, претендующей на поддержку стандарта SQL99. СУБД может не поддерживать ни одного уровня расширенного соответствия или поддерживать любые из них. Каждый уровень описывает набор возможностей языка SQL, которые должны поддерживать реализации СУБД, претендующие на данный уровень соответствия.

При этом объявлено, что стандарт SQL99 является открытым для всех последующих уровней расширенного соответствия, которые могут появиться в дальнейшем.

В настоящий момент стандарт SQL99 содержит следующие уровни соответствия:

• Функциональное ядро.
• Поддержка работы с датой/временем.
• Управление целостностью.
• Активные базы данных.
• OLAP.
• PSM-модули.
• CLI-интерфейс.
• Базовая поддержка объектов (Basic Object Support).
• Расширенная поддержка объектов (Enhanced Object Support).

Дата добавления: 2015-04-24