2. Проектирование бд. Проблемы проектирования бд

Проектирование ИМ, включающих в себя БД, осуществляется на физическом, концептуальном и логическом уровнях.

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

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

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

При проектировании структур данных для автоматизированных систем можно выделить 3 подхода:

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

Формирование знаний о системе (определение типов исходных данных и их взаимосвязей) и требований к обработке данных, полученных с помощью CASE-системы (система автоматизации проетирования и разработки БД), готовые схемы БД или даже готовой прикладной ИС.

Структурирование информации для использования в ИС в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

Основная цель проектирования БД - сокращение избыточности хранимых данных и, следовательно, экономия объёма используемой памяти, уменьшение затрат на многократные операции, обновлении избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте.

При проектировании базы данных решаются две основных проблемы:

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

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

В случае реляционных баз данных трудно представить какие-либо общие рецепты по части физического проектирования. Здесь слишком много зависит от используемой СУБД. Например, при работе с СУБД Ingres можно выбирать один из предлагаемых способов физической организации отношений, при работе с System R следовало бы прежде всего подумать о кластеризации отношений и требуемом наборе индексов и т.д. Поэтому в этом разделе мы ограничимся вопросами логического проектирования реляционных баз данных, которые существенны при использовании любой реляционной СУБД.

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

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