Модели организации баз данных

 

 

 

 

 

1. Уровни моделей базы данных

Разработка любой информационной системы включает в себя несколько  взаимно перекрывающихся во времени  процессов:

1. определение пользователей системы и формулировка их требований к ней;
2. анализ стоящей задачи;
3. проектирование (базы данных, приложений и т.д.);
4. реализация (в том числе, программирование);
5. документирование;
6. тестирование и возврат к одному из предыдущих процессов.

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

Результатом анализа  и проектирования информационной системы  являются модели. Они используются для следующих целей:

1. связывание понятий различных участников разработки информационной системы;
2. формализация и систематизация этих понятий (в т.ч. разбиение по категориям);
3. детальное описание (спецификация) компонентов системы и связей между ними;
4. анализ этих компонентов для лучшего понимания структуры системы и её дальнейшего развития (что возможно благодаря наглядному представлению модели).

Прежде всего, разработчики информационной системы создают  обобщенное и не слишком формальное описание базы данных, объединяя частные  представления об её содержимом, полученные из опроса пользователей (сотрудников организации, для которой предназначена система). Это описание, выполненное с использованием естественного языка, таблиц, формул, графиков и тому подобных средств, называют инфологической (или информационной, или концептуальной, или семантической) моделью данных (см. Рис. 2.1). Такая ориентированная на человека модель полностью независима от физических параметров среды хранения данных, и этой средой может быть, например, память человека, а не компьютера. Остальные модели ориентированы не на смысл (семантику) данных, а на их компьютерное представление. На базе второй модели – даталогической (или просто логической) – СУБД предоставляет доступ к хранимым данным лишь по их именам, не заботясь о физическом размещении этих данных. Даталогические модели должны быть описаны на языке описания данных этой СУБД (к счастью, разные СУБД имеют близкие языки, см. 1.3.2). Нужные данные отыскиваются СУБД на внешних запоминающих устройствах в соответствии с третьей – физической – моделью данных. Структура данных этой модели (данных конфигурации) уже слишком зависит от СУБД, поэтому в данном курсе она практически не рассматривается.

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

Данный курс напрямую касается лишь двух из перечисленных в начале этого раздела процессов разработки – проектирования БД (часть пункта 3) и реализации доступа к ней (часть пункта 4), которые в совокупности представляют собой формирование логической (даталогической) модели данных. Однако формулировку требований и анализ (пункты 1 и 2), результаты которых выражаются в семантической (инфологической) модели, также необходимо кратко рассмотреть, поскольку на них основывается дальнейшая работа по проектированию БД.

 

 

 

 

Этапы проектирования баз данных

 

Создание и внедрение  в практику современных информационных систем

автоматизированных баз  данных выдвигает новые задачи проектирования, которые

невозможно решать традиционными  приемами и методами. Большое внимание

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

успешно будет спроектирована база данных, зависит эффективность

функционирования системы  в целом, ее жизнеспособность и возможность

расширения и дальнейшего  развития. Поэтому вопрос проектирования баз данных

выделяют как отдельное, самостоятельное направление работ  при разработке

информационных систем.

     Проектирование баз данных — это итерационный, многоэтапный процесс

принятия обоснованных решений в процессе анализа информационной модели

предметной области, требований к данным со стороны прикладных программистов и

пользователей, синтеза  логических и физических структур данных, анализа и

обоснования выбора программных  и аппаратных средств. Этапы проектирования баз

данных связаны с  многоуровневой организацией данных. Рассматривая вопрос

проектирования баз  данных, будем придерживаться такого многоуровневого

представления данных: внешнего, инфологического, логического (даталогического)

и внутреннего.

Такое представление  уровней данных не единственное. Существуют и другие

варианты многоуровневого  представления данных. Так, в соответствии с

предложениями исследовательской  группы по системам управления данными

Американского национального  института стандартов ANSI/X3/SPARC, а  также

CODASYL (Conference on Data Systems Languages), как правило, выделяется три

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

     внешний уровень (с точки зрения конечного пользователя и прикладного

программиста),

     концептуальный уровень (с точки зрения СУБД),

     внутренний уровень (с точки зрения системного программиста).

В соответствии с этой концепцией внешний уровень это  часть (подмножество)

концептуальной модели, необходимая для реализации какого-либо запроса или

прикладной программы. То есть, если концептуальная модель выступает  как

схема, поддерживаемая конкретной СУБД, то внешний уровень — это некоторая

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

программы или запроса  пользователя.

Существует также другая точка зрения, в соответствии с  которой под внешним

уровнем понимают более общие понятия, связанные с изучением и анализом

информационных потоков  предметной области и их структуризацией. Некоторые

авторы вводят вспомогательный  уровень (промежуточный между внешним  и

даталогическим уровнями), который называется инфологическим. Он может

выступать как самостоятельный  или быть составной частью внешнего уровня.

Такая концепция более  целесообразна с точки зрения понимания процесса

проектирования БД.

Поэтому будем рассматривать  инфологический уровень как самостоятельный

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

отдельный этап проектирования, на котором изучается все внемашинное

информационное обеспечение, то есть формы документирования и  представления

данных, а также внешняя  среда, в которой будет функционировать банк данных с

точки зрения методов  фиксации, сбора и передачи информации в базу данных.

При проектировании БД на внешнем уровне необходимо изучить

функционирование объекта  управления, для которого проектируется  БД, всю

первичную и выходную документацию с точки зрения определения того, какие именно

данные необходимо сохранять  в базе данных. Внешний уровень  это, как правило,

словесное описание входных  и выходных сообщений, а также  данных, которые

целесообразно сохранять  в БД. Описание внешнего уровня не исключает наличия

элементов дублирования, избыточности и несогласованности  данных. Поэтому для

устранения этих аномалий и противоречий внешнего описания данных выполняется

инфологическое проектирование. Инфологическая модель является средством

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

Инфологическую модель можно рассматривать в основном как средство

документирования и  структурирования формы представления  информационных

потребностей, которая  обеспечивает непротиворечивое общение пользователей и

разработчиков системы.

Все внешние представления  интегрируются на инфологическом уровне, где

формируется инфологическая (каноническая) модель данных, которая  не является

простой суммой внешних  представлений данных.

     Инфологический уровень представляет собой информационно-логическую модель

(ИЛМ) предметной области,  из которой исключена избыточность  данных и отображены

информационные особенности  объекта управление без учета  особенностей и

специфики конкретной СУБД. То есть инфологическое представление данных

ориентированно преимущественно  на человека, который проектирует  или использует

базу данных.

     Логический (концептуальный) уровень построен с учетом специфики и

особенностей конкретной СУБД. Этот уровень представления  данных ориентирован

больше на компьютерную обработку и на программистов, которые  занимаются ее

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

специальным способом структурированная  модель предметной области, которая

отвечает особенностям и ограничениям выбранной СУБД. Модель логического уровня,

поддерживаемую средствами конкретной СУБД, называют еще даталогической.

Инфологическая и даталогическая модели, которые отображают модель одной

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

трансформироваться в  даталогическую модель.

     Внутренний уровень связан с физическим размещением данных в памяти ЭВМ.

На этом уровне формируется  физическая модель БД, которая включает структуры

сохранения данных в  памяти ЭВМ, в т.ч. описание форматов записей, порядок их

логического или физического  приведения в порядок, размещение по типам

устройств, а также  характеристики и пути доступа к  данным.

От параметров физической модели зависят такие характеристики функционирования

БД: объем памяти и  время реакции системы. Физические параметры БД можно

изменять в процессе ее эксплуатации с целью повышения  эффективности

функционирование системы. Изменение физических параметров не предопределяет

необходимости изменения  инфологической и даталогической моделей.

Схема взаимосвязи уровней  представления данных в БД изображена на рис. 4.1. В

соответствии с этими  уровнями проектируется БД. Проектирование БД— это

сложный и трудоемкий процесс, который требует привлечения  многих

высококвалифицированных специалистов. От того, насколько квалифицированно

спроектирована БД, зависят  производительность информационной системы  и

полнота обеспечения  функциональных потребностей пользователей  и прикладных

программ. Неудачно спроектированная БД может усложнить процесс разработки

прикладного программного обеспечения, обусловить необходимость  использования

более сложной логики, которая, в свою очередь, увеличит время  реакции

системы, а в дальнейшем может привести к необходимости  перепроектирования

логической модели БД. Реструктуризация или внесение изменений в логическую

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

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

Все работы, которые выполняются  на каждом этапе проектирования, должны

интегрироваться со словарем данных. Каждый этап проектирования

рассматривается как  определенная последовательность итеративных  процедур, в

результате которых  формируется определенная модель БД.

                             

      Рис. 4.1. Схема взаимосвязи уровней представление данных в БД     

     Внешний уровень — подготовительный этап инфологического проектирования

Целью проектирования на внешнем уровне является разработка внемашинного

информационного обеспечения, которое включает систему входной (первичной)

документации, характеризующую  определенную предметную область, систему

классификации и кодирования  технико-экономической информации, а также

перечень соответствующих  выходных сообщений, которые нужно  формировать с

помощью БнД.

Существуют два подхода  к проектированию баз данных на внешнем  уровне: «от

предметной области» и «от запроса». Подход «от предметной области» состоит в

том, что формируется внешнее информационное обеспечение всей предметной

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

этот подход называют еще объектным или непроцессным.

При подходе «от запроса» основным источником информации о предметной области

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

подход также называется процессным или функциональным. При  таком подходе БД

проектируется для выполнения текущих задач управления без  учета возможности

расширение системы и возникновение новых задач управление.

Преимущество подхода  «от предметной области» это его  объективность,