Проектирование БД – это упорядоченный, формализованный процесс создание системы взаимосвязанных описаний, т.е. таких моделей ПО, которые связывают хранимые в базе данные с объектами ПО, описываемые этими данными. Проектирование начинается с анализа ПО и выявления функциональных и других требований к проектируемой системе. Проектирование начинается с анализа ПО и выявления функциональных и других требований к проектируемой системе. Сначала создается обобщенное неформализованное описание создаваемой БД с использованием естественного языка, и т.д. Это инфологическая модель. Она конструктивно ограничивает область применения, а также определяет круг задач, которые будут решаться в рамках БД. Это человеко-ориентированная модель, почти не зависит от физических параметров среды хранения данных. Не изменяется до тех пор, пока изменения в реальном мире не позволят ей адекватно отражать ПО. Остальные модели машинно-ориентированные, с их помощью СУБД дает возможность программам пользователям осуществлять доступ к данным по их именам, не заботясь об их физическом расположении. Т.к. доступ к данным осуществляется с помощью конкретной СУБД, то модели должны быть представлены на ЯОД этой СУБД. Такое описание, созданное по инфологической модели называется даталогической моделью. Для размещения и поиска данных на внешних запоминающих устройствах СУБД использует физическую модель. Эта трехуровневая архитектура позволяет обеспечить независимость хранимых данных от использования их программ. Т.е. данные могут быть перезаписаны и реорганизованы на физическом уровне но это повлечет только изменение физической и возможно датологической модели, но не будет заметно для пользователя. Также независимость данных позволяет создавать новые приложения для решения новых задач без разрушения старых.
Начальной стадией проектирования системы баз данных является построение семантической модели предметной области, которая базируется на анализе свойств и природы объектов предметной области и информационных потребностей будущих пользователей разрабатываемой системы. Эту стадию принято называть концептуальным проектированием системы, а ее результат – концептуальной моделью. Назначение концептуальных моделей определяет и некоторые специфические требования к средствам их представления. Помимо упомянутой независимости от среды (оборудования) и требования адекватности отражения предметной области отметим следующие: • формализованность, обеспечивающую возможность автоматизированной обработки, в том числе, например, автоматический контроль непротиворечивости; • дружественность, обеспечивающую возможность использования наглядных графических средств отображения и обработки их пользователем. К концептуальным моделям относятся различные компоненты, по-разному и разными средствами отражающие предметную область. Помимо наиболее известного описания объектов и связей между ними (модель «сущность-связь») к концептуальному уровню описания предметной области можно отнести следующие компоненты:
• систему атрибутов и средств описания предметной области. Например, логические (автоматические) связи между показателями или лингвистические свойства языка (синонимию, синтаксис и т.д.), используемую для вербального представления объектов; • ограничения целостности, определяющие допустимость значения отдельных полей и взаимосвязей как на уровне семантики содержимого БД, так и ее физической структуры (отдельных файлов данных и взаимосвязей между ними);
• описание информационных потребностей пользователей, например, в виде типовых запросов, отражающих процедурные особенности обращения к данным. Задачей следующей стадии проектирования системы баз данных является выбор подходящей СУБД и отображение ее в среду (структуру данных) спецификаций инфологической модели предметной области. Другими словами, модель предметной области разрабатываемой системы должна быть представлена в терминах модели данных концептуального уровня выбранной конкретной СУБД. Эту стадию называют логическим (или даталогическим) проектированием базы данных, а ее результатом является концептуальная схема базы данных, включающая определение всех информационных элементов (единиц) и связей, в том числе задание типов, характеристик и имен. Хотя даталогическое проектирование оперирует не физическими записями, а логическими понятиями, связанными со структурой базы данных, тем не менее особенности представления данных, правила и языки агрегирования и манипулирования данными имеют определенное влияние. Не все виды связей, например, «многие ко многим», могут быть непосредственно отражены в логической модели.
Кроме того, может быть много вариантов отображения инфологической модели предметной области в даталогическую модель базы. Здесь следует учитывать влияние двух следующих значимых факторов, связанных с практикой разработки базы данных. Во-первых, связи предметной области могут отображаться двумя путями: как декларативным – в логической схеме, так и процедурным – отработкой связей через программные модули, обрабатывающие (связывающие) соответствующие хранимые данные. Во-вторых, существенным фактором может оказаться характер обработки информации. Например, частые обращения к совместно обрабатываемым данным, очевидно, предполагают их совместное хранение, а данные (особенно большого объема), к которым обращаются редко, целесообразно хранить отдельно от часто используемых. Стадия физического проектирования базы данных в общем случае включает: • выбор способа организации базы данных;
• разработку спецификации внутренней схемы средствами модели данных ее внутреннего уровня; • описание отображения концептуальной модели во внутреннюю.
Важно заметить, что в отличие от ранних СУБД, многие современные системы не предоставляют разработчику какого-либо на этой стадии. Реально к вопросам проектирования физической модели можно отнести выбор схемы размещения данных (разделение по файлам или тип RAID-массива) и определение числа и типа индексов (например, кластеризованный или некастеризованный в случае MS SQL Server). Способ хранения базы данных определяется механизмами СУБД автоматически «по умолчанию» на основе спецификаций концептуальной схемы базы данных, и внутренняя схема в явном виде в таких системах не используется. Следует также отметить, что внешние схемы базы данных обычно конструируются на стадии обработки приложений.
Базы данных сами по себе представляют относительную ценность. Базы данных – это всегда важнейшая, но только одна из составляющих некоторой информационной системы (ИС). И надо отметить, что любая информационная система, предназначенная, например, для оперативного управления предприятием или архивного хранения и поиска документов – это не только программы, данные и коммуникации, но и люди (заказчики, пользователи, аналитики, разработчики), организационные структуры, а также цели, стимулы работы предприятия или отдельных людей. И все эти компоненты должны быть понятными как проектировщику, так и пользователю, а кроме того, непротиворечивым образом соединены в одну систему. Главная идея процесса такого согласования состоит в том, что его надо начинать с анализа самых главных характеристик предметной области, рассматривая самые главные содержательные аспекты. И проводить его не «мысленно» и не «на словах», а на явно изложенных описаниях (моделях) объектов предметной области, позволяющих видеть все существенные взаимосвязи. Однако следует отметить, что попытки использования привычных нотаций формальных моделей (структурных, объектных или каких-либо других) на этом этапе приводят к более низкому (более детальному, и в то же время ограниченному) уровню представления предметной области, чем это необходимо для общего понимания. В общем случае существуют два подхода к определению состава и структуры предметной области. Функциональный подход предполагает, что проектирование начинается с анализа задач и, соответственно, функций, обеспечивающих реализацию информационных потребностей. При объектном (предметном) подходе информационные потребности пользователей (задачи) жестко не фиксируются, а основное внимании сосредотачивается на выделении существенных объектов – предметов и связей, информация о которых может быть использована в прикладных задачах пользователя. Условность такого деления достаточно очевидна, поэтому на практике используются компромиссные варианты, предполагающие по мере развития системы расширение как состава объектов, так и спектра прикладных задач. Модель ИС Захмана – простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее «обеспечения», а также их взаимосвязи. Три столбца означают три раздела обеспечения системы: информационный (ДАННЫЕ), функциональный (ФУНКЦИИ) и коммуникационный (СЕТЬ). Строки таблицы означают шесть уровней представления системы: реальная среда приложений, концептуальная модель, логическая модель, физическая модель, детальная реализация процедур, представления пользователя. Полезность такой схемы состоит в том, что она помогает рассматривать задачи проекта в полном объеме, упорядочивать состав и структуру требований к системе, определять и фиксировать причинно-следственные связи. Позднее появилось развитие такой «плоской» модели. Рассматривалась схема, включающая три новых столбца, в которых отражаются еще три раздела: побудительные причины действий системы, события и графики выполнения действий, а также «действующие лица» - люди и организационные структуры. В результате появилось шесть разделов, которые содержат «ответы на вопросы»: почему выполняются действия, когда выполняются и кто их выполняет, а также что делает система, как делает и где. При этом уровни представления (строки таблицы) остались те же. Такое расширение позволило рассматривать потребности в контексте информационных технологий, соединять предметы и действия с человеческим фактором и операционной динамикой процессов.
