Модели организации баз данных (стр. 3 из 3)

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

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

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

Создание и внедрение в практику современных информационных системавтоматизированных баз данных выдвигает новые задачи проектирования, которыеневозможно решать традиционными приемами и методами. Большое вниманиенеобходимо уделять вопросам проектирования баз данных. От того, насколькоуспешно будет спроектирована база данных, зависит эффективностьфункционирования системы в целом, ее жизнеспособность и возможностьрасширения и дальнейшего развития. Поэтому вопрос проектирования баз данныхвыделяют как отдельное, самостоятельное направление работ при разработкеинформационных систем. Проектирование баз данных — это итерационный, многоэтапный процесспринятия обоснованных решений в процессе анализа информационной моделипредметной области, требований к данным со стороны прикладных программистов ипользователей, синтеза логических и физических структур данных, анализа иобоснования выбора программных и аппаратных средств. Этапы проектирования базданных связаны с многоуровневой организацией данных. Рассматривая вопроспроектирования баз данных, будем придерживаться такого многоуровневогопредставления данных: внешнего, инфологического, логического (даталогического)и внутреннего.Такое представление уровней данных не единственное. Существуют и другиеварианты многоуровневого представления данных. Так, в соответствии спредложениями исследовательской группы по системам управления даннымиАмериканского национального института стандартов ANSI/X3/SPARC, а такжеCODASYL (Conference on Data Systems Languages), как правило, выделяется триуровня представления данных: внешний уровень (с точки зрения конечного пользователя и прикладногопрограммиста), концептуальный уровень (с точки зрения СУБД), внутренний уровень (с точки зрения системного программиста).В соответствии с этой концепцией внешний уровень это часть (подмножество)концептуальной модели, необходимая для реализации какого-либо запроса илиприкладной программы. То есть, если концептуальная модель выступает каксхема, поддерживаемая конкретной СУБД, то внешний уровень — это некотораясовокупность подсхем, необходимых для реализации конкретной прикладнойпрограммы или запроса пользователя.Существует также другая точка зрения, в соответствии с которой под внешнимуровнем понимают более общие понятия, связанные с изучением и анализоминформационных потоков предметной области и их структуризацией. Некоторыеавторы вводят вспомогательный уровень (промежуточный между внешним идаталогическим уровнями), который называется инфологическим. Он можетвыступать как самостоятельный или быть составной частью внешнего уровня.Такая концепция более целесообразна с точки зрения понимания процессапроектирования БД.Поэтому будем рассматривать инфологический уровень как самостоятельныйуровень представления данных. Внешний уровень в этом случае выступает какотдельный этап проектирования, на котором изучается все внемашинноеинформационное обеспечение, то есть формы документирования и представленияданных, а также внешняя среда, в которой будет функционировать банк данных сточки зрения методов фиксации, сбора и передачи информации в базу данных.При проектировании БД на внешнем уровне необходимо изучитьфункционирование объекта управления, для которого проектируется БД, всюпервичную и выходную документацию с точки зрения определения того, какие именноданные необходимо сохранять в базе данных. Внешний уровень это, как правило,словесное описание входных и выходных сообщений, а также данных, которыецелесообразно сохранять в БД. Описание внешнего уровня не исключает наличияэлементов дублирования, избыточности и несогласованности данных. Поэтому дляустранения этих аномалий и противоречий внешнего описания данных выполняетсяинфологическое проектирование. Инфологическая модель является средствомструктуризации предметной области и понимания концепции семантики данных.Инфологическую модель можно рассматривать в основном как средстводокументирования и структурирования формы представления информационныхпотребностей, которая обеспечивает непротиворечивое общение пользователей иразработчиков системы.Все внешние представления интегрируются на инфологическом уровне, гдеформируется инфологическая (каноническая) модель данных, которая не являетсяпростой суммой внешних представлений данных. Инфологический уровень представляет собой информационно-логическую модель(ИЛМ) предметной области, из которой исключена избыточность данных и отображеныинформационные особенности объекта управление без учета особенностей испецифики конкретной СУБД. То есть инфологическое представление данныхориентированно преимущественно на человека, который проектирует или используетбазу данных. Логический (концептуальный) уровень построен с учетом специфики иособенностей конкретной СУБД. Этот уровень представления данных ориентированбольше на компьютерную обработку и на программистов, которые занимаются ееразработкой. На этом уровне формируется концептуальная модель данных, то естьспециальным способом структурированная модель предметной области, котораяотвечает особенностям и ограничениям выбранной СУБД. Модель логического уровня,поддерживаемую средствами конкретной СУБД, называют еще даталогической.Инфологическая и даталогическая модели, которые отображают модель однойпредметной области, зависимы между собой. Инфологическая модель может легкотрансформироваться в даталогическую модель. Внутренний уровень связан с физическим размещением данных в памяти ЭВМ.На этом уровне формируется физическая модель БД, которая включает структурысохранения данных в памяти ЭВМ, в т.ч. описание форматов записей, порядок ихлогического или физического приведения в порядок, размещение по типамустройств, а также характеристики и пути доступа к данным.От параметров физической модели зависят такие характеристики функционированияБД: объем памяти и время реакции системы. Физические параметры БД можноизменять в процессе ее эксплуатации с целью повышения эффективностифункционирование системы. Изменение физических параметров не предопределяетнеобходимости изменения инфологической и даталогической моделей.Схема взаимосвязи уровней представления данных в БД изображена на рис. 4.1. Всоответствии с этими уровнями проектируется БД. Проектирование БД— этосложный и трудоемкий процесс, который требует привлечения многихвысококвалифицированных специалистов. От того, насколько квалифицированноспроектирована БД, зависят производительность информационной системы иполнота обеспечения функциональных потребностей пользователей и прикладныхпрограмм. Неудачно спроектированная БД может усложнить процесс разработкиприкладного программного обеспечения, обусловить необходимость использованияболее сложной логики, которая, в свою очередь, увеличит время реакциисистемы, а в дальнейшем может привести к необходимости перепроектированиялогической модели БД. Реструктуризация или внесение изменений в логическуюмодель БД это очень нежелательный процесс, поскольку он является причинойнеобходимости модификации или даже перепрограммирование отдельных задач.Все работы, которые выполняются на каждом этапе проектирования, должныинтегрироваться со словарем данных. Каждый этап проектированиярассматривается как определенная последовательность итеративных процедур, врезультате которых формируется определенная модель БД. Рис. 4.1. Схема взаимосвязи уровней представление данных в БД Внешний уровень — подготовительный этап инфологического проектированияЦелью проектирования на внешнем уровне является разработка внемашинногоинформационного обеспечения, которое включает систему входной (первичной)документации, характеризующую определенную предметную область, системуклассификации и кодирования технико-экономической информации, а такжеперечень соответствующих выходных сообщений, которые нужно формировать спомощью БнД.Существуют два подхода к проектированию баз данных на внешнем уровне: «отпредметной области» и «от запроса». Подход «от предметной области» состоит втом, что формируется внешнее информационное обеспечение всей предметнойобласти без учета потребностей пользователей и прикладных программ. Иногдаэтот подход называют еще объектным или непроцессным.При подходе «от запроса» основным источником информации о предметной областиесть изучение запросов пользователей и потребностей прикладных программ. Этотподход также называется процессным или функциональным. При таком подходе БДпроектируется для выполнения текущих задач управления без учета возможностирасширение системы и возникновение новых задач управление.Преимущество подхода «от предметной области» это его объективность,системность при отображении ПО и стойкость информационной модели, возможностьреализации большого количества прикладных программ и запросов, в том численезапланированных при создании БД. Недостатком этого подхода являетсязначительный объем работ, которые необходимо выполнить при определенииинформации. подлежащей хранению в БД, что, соответственно, усложняет иувеличивает срок разработки проекта.Функциональный подход ориентирован на реализацию текущих требованийпользователей и прикладных программ без учета перспектив развития системы.При его использовании могут возникнуть сложности в агрегации требованийразных пользователей и прикладных программ. Тем не менее, при таком подходезначительно уменьшается трудоемкость проектирования, и поэтому возможносоздать систему с высокими эксплуатационными характеристиками.Однако взятый в отдельности любой из этих методов не может дать достаточноинформации для проектирования рациональной структуры БД. Поэтому припроектировании БД целесообразно совместно использовать эти два подхода. Еслисхематично представить процесс проектирования БД на внешнем уровне, то онсостоит из таких работ.1. Определение функциональных задач предметной области, которыеподлежат автоматизированному решению. Поскольку основной целью создания БДесть обеспечение информацией функций обработки данных, то, прежде всего,необходимо изучить все функции предметной области (объекта управления), длякоторой разрабатывается база данных, и проанализировать их особенности.Функции и функциональные особенности объекта управление необходимо изучать внеразрывной связи с изучением функциональных требований к данным со стороныбудущих пользователей информационной системы. Изучение и анализпредусматривают выявление информационных потребностей и определенияинформационных потоков. Эти работы можно выполнять обследованием предметнойобласти и анкетированием ее сотрудников. Результатом такого изучения можетбыть перечень функциональных задач, которые должны решатьсяавтоматизированным способом с использованием БД.2. Изучение и анализ оперативных первичных документов. Изучив функции иопределив перечень функциональных задач, которые подлежат автоматизированномурешению, переходят к изучению оперативных документов, которые используются навходе каждой задачи или их комплекса. Изучив и проанализировав всеоперативные документы (как внешние, так и внутренние), которые используютсяна входе каждой задачи, определяют, какие реквизиты этих документов нужносохранять в БД.3. Изучение нормативно-справочных документов. На третьем шаге изучают ианализируют всю нормативно-справочную документацию. К такой документациипринадлежат различные классификаторы, сметы, договоры, нормативы,законодательные акты по налоговой политике, плановая документация и т.п.Распределение и отдельный анализ оперативной и нормативно-справочнойинформации обусловлены технологически. В базы данных различаются технологиисоздания и ведения файлов условно-постоянной информации, размещенной внормативно-справочной документации, и файлов оперативной информации.4. Изучение процессов преобразования входных сообщений в выходные.Прежде всего, изучаются все выходные сообщения, которые выдаются на печатьили на экран и сохраняются в виде выходных массивов на МД. Это необходимо длятого, чтобы определить, которые из атрибутов входных сообщений нужносохранять в БД для получения выходных сообщений. Кроме того, на этом этапеопределяются те показатели, которые получают во время решения задачи врезультате выполнения определенных вычислений. По каждому расчетномупоказателю следует определить алгоритм его формирования и убедиться в том,что этот показатель можно получить на основе атрибутов оперативной инормативно-справочной информации, которые были определены на втором и третьемшагах. Если определенных данных не хватает для полного выполнения расчетов,необходимо возвратиться назад, провести дополнительное исследование иопределить, где и каким способом можно получить атрибуты, которых не хватает.Кроме того, нужно определиться, какие из расчетных показателей целесообразносохранять в БД. Показатели, полученные расчетным путем, как правило, в БД несохраняются. Исключением являются случаи, когда расчетный показатель нужноиспользовать для решения других задач или для данной задачи, но в следующиекалендарные периоды.При проведении проектных работ на внешнем уровне надо учитывать то, что длявыполнения определенных функций в БД необходимо сохранять дополнительныеданные, которые не отображены в документах (данные календаря, статистическиеданные и т.п.). Обобщенная схема процесса изучения документов и данных припроектировании на внешнем уровне изображена на рис. 4.2. Рис.4.2. Обобщенная схема процесса проектирование на внешнем уровне Такое изучение необходимо провести по каждой функциональной задаче или ихкомплексу, которые будут решаться с помощью БД.Результатом проектирования на внешнем уровне будет перечень атрибутов(реквизитов) оперативной и условно-постоянной информации, которые необходимохранить в БД, с указанием источников их получения и формы представления.Однако этот перечень не исключает возможности существования в немизбыточности, дублирования, несогласованности и других недостатков. Поэтомуна этом процесс не заканчивается, а осуществляется переход к этапуинфологического проектирования.