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

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

базу данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                             

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

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

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

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

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

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

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

помощью БнД.

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

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

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

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

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

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

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

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

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

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

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

системность при  отображении ПО и стойкость информационной модели, возможность

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

незапланированных при создании БД. Недостатком этого  подхода является

значительный объем  работ, которые необходимо выполнить  при определении

информации. подлежащей хранению в БД, что, соответственно, усложняет и

увеличивает срок разработки проекта.

Функциональный  подход ориентирован на реализацию текущих  требований

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

При его использовании  могут возникнуть сложности в  агрегации требований

разных пользователей  и прикладных программ. Тем не менее, при таком подходе

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

создать систему  с высокими эксплуатационными характеристиками.

Однако взятый в отдельности любой из этих методов  не может дать достаточно

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

проектировании  БД целесообразно совместно использовать эти два подхода. Если

схематично представить  процесс проектирования БД на внешнем  уровне, то он

состоит из таких  работ.

1.       Определение функциональных задач предметной области, которые

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

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

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

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

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

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

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

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

информационных  потоков. Эти работы можно выполнять  обследованием предметной

области и анкетированием ее сотрудников. Результатом такого изучения может

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

автоматизированным  способом с использованием БД.

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

определив перечень функциональных задач, которые подлежат автоматизированному

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

входе каждой задачи или их комплекса. Изучив и проанализировав  все

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

на входе каждой задачи, определяют, какие реквизиты этих документов нужно

сохранять в БД.

3.       Изучение нормативно-справочных  документов. На третьем шаге изучают  и

анализируют всю  нормативно-справочную документацию. К такой документации

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

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

Распределение и  отдельный анализ оперативной и  нормативно-справочной

информации обусловлены  технологически. В базы данных различаются  технологии

создания и ведения  файлов условно-постоянной информации, размещенной в

нормативно-справочной документации, и файлов оперативной  информации.

4.       Изучение процессов преобразования  входных сообщений в выходные.

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

или на экран и  сохраняются в виде выходных массивов на МД. Это необходимо для

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

сохранять в БД для получения выходных сообщений. Кроме того, на этом этапе

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

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

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

что этот показатель можно получить на основе атрибутов  оперативной и

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

шагах. Если определенных данных не хватает для полного  выполнения расчетов,

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

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

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

сохранять в БД. Показатели, полученные расчетным путем, как правило, в БД не

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

использовать для  решения других задач или для  данной задачи, но в следующие

календарные периоды.

При проведении проектных  работ на внешнем уровне надо учитывать  то, что для

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

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

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

проектировании  на внешнем уровне изображена на рис. 4.2.

                             

   Рис.4.2. Обобщенная схема процесса проектирование на внешнем уровне  

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

комплексу, которые будут решаться с помощью БД.

Результатом проектирования на внешнем уровне будет перечень атрибутов

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

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

Однако этот перечень не исключает возможности существования в нем

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

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