Загрузка...
Учебная работа. Реферат: Модели организации баз данных
Инфологическая модель обязана быть отображена в компьютеро-ориентированную даталогическую модель, «понятную» СУБД. В процессе развития теории и практического использования баз данных, также средств вычислительной техники создавались СУБД, поддерживающие разные даталогические модели.
Поначалу стали применять иерархические даталогические модели. Простота организации, наличие заблаговременно данных связей меж сущностями, сходство с физическими моделями данных дозволяли добиваться применимой производительности иерархических СУБД на неспешных ЭВМ с очень ограниченными размерами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании достигнуть подходящей производительности.
Сетевые модели также создавались для не много ресурсных ЭВМ . Это довольно сложные структуры, состоящие из «наборов» – поименованных двухуровневых деревьев. «Наборы» соединяются при помощи «записей-связок», образуя цепочки и т.д. При разработке сетевых моделей было придумано огромное количество «малеханьких хитростей», позволяющих прирастить производительность СУБД, но значительно усложнивших крайние. Прикладной программер должен знать массу определений, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для воплощения навигации посреди разных экземпляров, наборов, записей и т.п. один из разрабов операционной системы UNIX произнес «Сетевая база – это самый верный метод утратить данные».
Сложность практического использования иерархических и и сетевых СУБД заставляла находить другие методы представления данных. В конце 60-х годов возникли СУБД на базе инвертированных файлов, отличающиеся простотой организации и наличием очень комфортных языков манипулирования данными. Но такие СУБД владеют ограничений на количество файлов для хранения данных, количество связей меж ними, длину записи и количество ее полей.
Сейчас более всераспространены реляционные модели, которые будут тщательно рассмотрены в главе 3.
Физическая организация данных оказывает основное воздействие на эксплуатационные свойства БД. Создатели СУБД пробуют сделать более производительные физические модели данных, предлагая юзерам тот либо другой инструментарий для поднастройки модели под определенную БД. Обилие методов корректировки физических моделей современных промышленных СУБД не дозволяет разглядеть их в этом разделе.
Модели организации баз данных
1. Иерархический подход к организации баз данных.
Иерархические базы данных имеют форму деревьев с дугами-связями и узлами-элементами данных. Иерархическая структура подразумевала неравноправие меж данными – одни агрессивно подчинены остальным. Подобные структуры, непременно, верно удовлетворяют требованиям почти всех, но далековато не всех настоящих задач.
2.
Сетевая модель данных.
В сетевых БД вместе с вертикальными реализованы и горизонтальные связи. Но унаследованы почти все недочеты иерархической и основной из их, необходимость верно определять физически связи данных и настолько же верно следовать данной для нас структуре связей при запросах к базе.
3. Реляционная модель.
Реляционная модель возникла вследствие рвения создать базу данных как можно наиболее гибкой. Данная модель предоставила обычной и действенный механизм поддержания связей данных.
Во-1-х
, все данные в модели представляются в виде таблиц и лишь таблиц. Реляционная модель – единственная из всех обеспечивает единообразие представления данных. И сути, и связи этих самых сущностей представляются в модели совсем идиентично –
. правда, таковой подход усложняет осознание смысла лежащей в базе данных инфы, и, как следствие, манипулирование данной для нас информацией.
Избежать проблем манипулирования дозволяет 2-ой элемент
модели – реляционно-полный язык (отметим, что язык является неотъемлемой частью хоть какой модели данных, без него модель не существует). Полнота языка в приложении к реляционной модели значит, что он должен делать всякую операцию реляционной алгебры либо реляционного исчисления (полнота крайних подтверждена математически Э.Ф. Коддом). Наиболее того, язык должен обрисовывать хоть какой запрос в виде операций с таблицами, а не с их строчками. Одним из таковых языков является SQL.
3-ий элемент
реляционной модели просит от реляционной модели поддержания неких ограничений целостности. Одно из таковых ограничений утверждает, что любая строчка в таблице обязана иметь некоторый неповторимый идентификатор, именуемый
. 2-ое ограничение накладывается на целостность ссылок меж таблицами. Оно утверждает, что атрибуты таблицы, ссылающиеся на первичные ключи остальных таблиц, обязаны иметь одно из значений этих первичных ключей.
4. Объектно-ориентированная модель.
Новейшие области использования вычислительной техники, такие как исследования, автоматическое проектирование и автоматизация учреждений, востребовали от баз данных возможности хранить и обрабатывать новейшие объекты – текст, аудио- и видеоинформацию, также документы. Главные трудности объектно-ориентированного моделирования данных проистекают из того, что такового развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует. В большенный степени потому до сего времени нет базисной объектно-ориентированной модели. С иной стороны, некие создатели говорят, что общая объектно-ориентированная модель данных в традиционном смысле и не быть может определена из-за непригодности традиционного понятия модели данных к парадигме объектной ориентированности. Невзирая на достоинства объектно-ориентированных систем – реализация сложных типов данных, связь с языками программирования и т.п. – на наиблежайшее время приемущество реляционных СУБД гарантировано.
5.3.3 Модели данных и концептуальное моделирование
Выше уже упоминалось, что схема создается при помощи некого языка определения данных. По сути она создается на базе языка определения данных определенной мотивированной СУБД, являющегося языком относительно низкого уровня; с его помощью тяжело обрисовать требования к данным так, чтоб сделанная схема была доступна осознанию юзеров самых различных категорий. Чтоб достигнуть такового осознания, требуется составить описание схемы на неком, наиболее высочайшем уровне, которое будем именовать моделью данных. При всем этом под моделью данных мы будем осознавать встроенный набор понятий для описания данных, связей меж ними и ограничений, накладываемых на данные в границах некой предметной области.
Модель является представлением объектов и событий предметной области, также имеющихся меж ними связей. Модель данных можно разглядывать как сочетание 3-х обозначенных ниже компонент.
· Структурная часть, т.е. набор правил, по которым быть может построена база данных.
· Управляющая часть, определяющая типы допустимых операций с данными (сюда относятся операции обновления и извлечения данных, также операции конфигурации структуры базы данных).
· Набор ограничений поддержки целостности данных , гарантирующих правильность применяемых данных.
Цель построения модели данных заключается в представлении данных в понятном виде. Если такое много моделей данных. Они разделяются на три группы: объектные (object-based) модели данных, модели данных на базе записей (record-based) и физические модели данных. 1-ые две употребляются для описания данных на концептуальном и наружном уровнях, а крайняя — на внутреннем уровне.
Объектные модели данных.
При построении объектных моделей данных употребляются такие понятия как сути, атрибуты и связи. Суть — это отдельный элемент (сотрудник, изделие, понятие либо событие) предметной области, который должен быть представлен в базе данных. Атрибут — это свойство, которое обрисовывает некий нюанс объекта и
- Модель типа «сущность-связь», либо ER-модель (Entity-Relationship model).
- Семантическая модель.
- Многофункциональная модель.
- Объектно-ориентированная модель.
В истинное время ER-модель стала одним из главных способов концептуального проектирования баз данных. Объектно-ориентированная модель расширяет определение сути с целью включения в него не только лишь атрибутов, которые обрисовывают состояние объекта, да и действий, которые с ним соединены, т.е. его состояние и поведение.
Модели данных на базе записей. В модели на базе записей база данных состоит из нескольких записей фиксированного формата, которые могут иметь различные типы. Любой тип записи описывает фиксированное количество полей, каждое из которых имеет фиксированную длину. Существует три главных типа логических моделей данных на базе записей: реляционная модель данных (relational data model), сетевая модель данных (Network data model) и иерархическая модель данных (hierarchical data model).
Реляционная модель данных.
Реляционная модель данных базирована на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц, любая из которых имеет несколько столбцов с неповторимыми именами.
При всем этом в реляционной модели данных единственное требование заключается в том, чтоб база данных исходя из убеждений юзера смотрелась как набор таблиц. Но такое восприятие относится лишь к логической структуре базы данных, т.е. к наружному и концептуальному уровням архитектуры ANSI/SPARC. Оно не относится к физической структуре базы данных, которая быть может реализована при помощи различных структур хранения.
Сетевая модель данных.
В сетевой модели данные представлены в виде коллекций записей, а связи — в виде наборов. В отличие от реляционной модели, связи тут очевидным образом моделируются наборами, которые реализуются при помощи указателей. Сетевую модель можно представить как граф с записями в виде узлов графа и наборами в виде его ребер.
Иерархическая модель данных.
Иерархическая модель является ограниченным подтипом сетевой модели. В ней данные также представлены как коллекции записей, а связи — как наборы. Но в иерархической модели узел может иметь лишь 1-го родителя. Иерархическая модель быть может представлена как древовидный граф с записями в виде узлов (которые также именуются секторами) и огромными количествами в виде ребер. Для моделирования инфы при помощи древовидной структуры употребляется обобщенное дерево, состоящее из узлов, соединенных связями, именуемых дугами либо ребрами. Самый верхний узел именуется корневым узлом. В структуре дерева могут быть выделены поддеревья, каждое из которых исходит из 1-го родительского узла (дочернего для узла наиболее высочайшего уровня). Все узлы дерева, кроме корневого, обязаны иметь родительский узел. Узлы представляют интересующие нас объекты, а связи меж ними определяются самим расположением узлов и ребер, образующих данную древовидную структуру.
Основанные на записях (логические) модели данных употребляются для определения общей структуры базы данных и высокоуровневого описания ее реализации. Их главный недочет состоит в том, что они не дают адекватных средств для очевидного указания ограничений, накладываемых на данные. В то же время в объектных моделях данных отсутствуют средства указания их логической структуры, но за счет предоставления юзеру способности указать ограничения для данных, они разрешают в большей мере представить семантическую сущность хранимой инфы.
Большая часть современных систем БД основано на реляционной парадигме, тогда как самые 1-ые системы баз данных строились на базе сетевой либо иерархической модели. При использовании крайних 2-ух моделей от юзера требуется познание физической организации базы данных, к которой он должен производить доступ, в то время как при работе с реляционной моделью независимость от данных обеспечивается в существенно большей степени. Как следует, если в реляционных системах для обработки инфы в базе данных принят декларативный подход (т.е. они указывают, какие данные следует извлечь), то в сетевых и иерархических системах — навигационный подход (т.е. они указывают, как их следует извлечь).
Физические модели данных.
Физические модели данных обрисовывают то, как данные хранятся в компе, представляя информацию о структуре записей, их упорядоченности и имеющихся путях доступа.
Концептуальное моделирование.
Как указывает исследование трехуровневой архитектуры СУБД, мировозренческая схема является » обеспечивающий ток крови по сосудам»>сердечком
» базы данных. Она поддерживает все наружные представления, а сама поддерживается средствами внутренней схемы. Но внутренняя схема является всего только физическим воплощением концептуальной схемы. Конкретно мировозренческая схема призвана быть полным и четким представлением требований к данным в рамках некой предметной области. В неприятном случае определенная часть инфы о предприятии будет упущена либо искажена, в итоге чего же могут появиться трудности при попытках полной реализации 1-го либо нескольких наружных представлений.
Концептуальное моделирование базы данных — это процесс конструирования модели использования инфы. Этот процесс не зависит от таковых подробностей, как применяемая СУБД, прикладные программки, языки программирования либо любые остальные вопросцы физической организации инфы. Схожая модель именуется концептуальной моделью данных.
Первой и важнейшей функцией базы данных, является функция хранения инфы. информация обязана хранится упорядоченно для наиболее резвого и понятного юзеру доступа к ней. Упорядоченность инфы в базе данных, кроме удобств доступа, может привести к значительному сокращению аппаратных ресурсов, нужных для ее обслуживания. Упорядоченность достигается методом нормализации.
тут мы впритирку подошли ко 2-ой функции базы данных – ввод инфы. Какую информацию будет вводить юзер? Отменная база данных построена из головного документа, справочников, из которых юзер вводит информацию и нескольких полей для ручного ввода, к примеру, текстов предназначения платежа в платежных поручениях и суммы. база данных обязана заполняться средствами, более много автоматизирующими этот процесс. При всем этом нехорошим тоном являются:
ввод инфы о одном объекте различными методами либо в различных местах;
ввод одной и той же инфы в нескольких местах;
ввод инфы разрозненно, без поддержания общей структуры объекта. одной из главных функций базы данных является автоматизация. Под автоматизацией, обычно, соображают автоматическое создание выходных документов и пересчет данных, к примеру печать затратной, счета фактуры и протокола согласования цен в складской программке для исходящей затратной.
Дальше, необходимо вспомянуть о системах принятия решений. Информационная система обязана позволять создавать статистические отчеты в настоящем режиме времени о состоянии описываемого в базе данных процесса. Эта функция комфортна для управляющих подразделений, которые могут предсказывать системы являются “джентльменским набором”, которого довольно почти всегда. Из доп функций нужно упомянуть возможность поиска по нескольким взаимосвязанным чертам.
В единой информационной системе нужна возможность идентификации юзера с целью ограничения доступа юзера к определенным частям базы данных и введения инфы о создателе документа и лиц, редактировавших его. Это даст юзерам чувство ответственности за выполняемые деяния.
Отменная информационная система обязана просто расширяться по мере необходимости прибавления в нее новейших способностей. Расширяемость предполагает элементы объектной ориентированности, интегрированные в базу данных. Настраивая эти объекты, может быть заносить незначимые конфигурации в структуру базы данных, что продляет срок морального устаревания всей информационной системы. Одним из причин расширяемости является возможность сочленять разнородные базы данных в единый комплекс. Таковая возможность на данный момент реализуется через доп модули, которые по собственной сущности являются серверами приложений, либо правильное построение базы данных по традиционным реляционным законам. Крайний вариант затрудняется тем, что некие серверы базы данных не могут выполнить один SQL запрос к различным базам данных, тем наиболее находящимся в географической удаленности друг от друга. Еще одна комфортная функция в базе данных – это сквозное прохождение по документам.
Описанные выше функции в различных реализациях информационных систем имеют специальные черты, направленные на конкретное прикладное внедрения.
1.
Разработка хоть какой информационной системы содержит в себе несколько взаимно перекрывающихся во времени действий:
1. определение юзеров системы и формулировка их требований к ней;
2. анализ стоящей задачки;
3. проектирование (базы данных, приложений и т.д.);
4. реализация (в том числе, программирование);
5. документирование;
6. тестирование и возврат к одному из прошлых действий.
Следует увидеть, что анализ и проектирование базы данных являются самыми ответственными частями работы, так как от одной БД обычно зависит создание сходу почти всех приложений, а требования к БД изменяются медлительнее, тем требования к приложениям. Чем крупнее информационная система, тем больший упор должен быть изготовлен на проектирование базы данных по сопоставлению с остальными действиями разработки.
Результатом анализа и проектирования информационной системы являются модели. Они употребляются для последующих целей:
1. связывание понятий разных участников разработки информационной системы;
2. формализация и классификация этих понятий (в т.ч. разбиение по категориям);
3. детализированное описание (спецификация) компонент системы и связей меж ними;
4. анализ этих компонент для наилучшего осознания структуры системы и её предстоящего развития (что может быть благодаря приятному представлению модели).
До этого всего, создатели информационной системы делают обобщенное и не очень формальное описание базы данных, объединяя личные представления о её содержимом, приобретенные из опроса юзеров (служащих организации, для которой предназначена система). Это описание, выполненное с внедрением естественного языка, таблиц, формул, графиков и тому схожих средств, именуют инфологической
(либо информационной
, либо концептуальной
, либо семантической
) моделью данных (см. Рис. 2.1). Таковая направленная на человека модель стопроцентно независима от физических характеристик среды хранения данных, и данной для нас средой быть может, к примеру, память человека, а не компа. Другие модели нацелены не на смысл (семантику) данных, а на их компьютерное Счастью, различные СУБД имеют близкие языки, см. 1.3.2). Нужные данные отыскиваются СУБД на наружных запоминающих устройствах в согласовании с третьей – физической
– моделью данных. структура данных данной для нас модели (данных конфигурации) уже очень зависит от СУБД, потому в данном курсе она фактически не рассматривается.
Три уровня моделей БД (семантический, логический и физический) обеспечивают независимость данных от использующих их приложений
. Разраб (либо админ) информационной системы может по мере необходимости переписывать данные на остальные носители инфы, улучшить их физическую структуру и даже переносить систему на другую СУБД, изменяя тем только физическую модель данных. Он также может подключить к системе хоть какое число новейших юзеров и новейших приложений, дополняя, если нужно, логическую модель. Обозначенные конфигурации физической и логической моделей не будут увидены существующими юзерами системы, которые работают с БД на семантическом уровне. Приложения же зависят от данных логического уровня, потому их код может изменяться, но при правильном проектировании БД конфигурации ерундовы.
Данный курс впрямую касается только 2-ух из перечисленных сначала этого раздела действий разработки – проектирования БД (часть пт 3) и реализации доступа к ней (часть пт 4), которые в совокупы представляют собой формирование логической (даталогической) модели данных. Но формулировку требований и анализ (пункты 1 и 2), результаты которых выражаются в семантической (инфологической) модели, также нужно коротко разглядеть, так как на их основывается предстоящая работа по проектированию БД.
Этапы проектирования баз данных
Создание и внедрение в практику современных информационных системавтоматизированных баз данных выдвигает новейшие задачки проектирования, которыеневозможно решать классическими приемами и способами. Огромное вниманиенеобходимо уделять вопросцам проектирования баз данных. От того, насколькоуспешно будет спроектирована база данных, зависит эффективностьфункционирования системы в целом, ее жизнеспособность и возможностьрасширения и предстоящего развития. Потому вопросец проектирования баз данныхвыделяют как отдельное, самостоятельное направление работ при разработкеинформационных систем.
— это итерационный, многоэтапный процесспринятия обоснованных решений в процессе анализа информационной моделипредметной области, требований к данным со стороны прикладных программистов ипользователей, синтеза логических и физических структур данных, анализа иобоснования выбора программных и аппаратных средств. Этапы проектирования базданных соединены с многоуровневой организацией данных. Рассматривая вопроспроектирования баз данных, будем придерживаться такового многоуровневогопредставления данных: наружного, инфологического, логического (даталогического)и внутреннего.Такое согласовании спредложениями исследовательской группы по системам управления даннымиАмериканского государственного института эталонов ANSI/X3/SPARC, а такжеCODASYL (Conference on Data Systems Languages), как правило, выделяется триуровня представления данных: наружный
уровень (исходя из убеждений конечного юзера и прикладногопрограммиста), концептуальный
уровень (исходя из убеждений СУБД), внутренний
уровень (исходя из убеждений системного программера).В согласовании с данной для нас концепцией наружный уровень это часть (подмножество)концептуальной модели, нужная для реализации какого-нибудь запроса илиприкладной программки. Другими словами, если мировозренческая модель выступает каксхема, поддерживаемая определенной СУБД, то наружный уровень — это некотораясовокупность подсхем, нужных для реализации определенной прикладнойпрограммы либо запроса юзера.Существует также иная точка зрения, в согласовании с которой под внешнимуровнем соображают наиболее общие понятия, связанные с исследованием и анализоминформационных потоков предметной области и их структуризацией. Некоторыеавторы вводят вспомогательный уровень (промежный меж наружным идаталогическим уровнями), который именуется инфологическим. Он можетвыступать как самостоятельный либо быть составной частью наружного уровня.Таковая теория наиболее целесообразна исходя из убеждений осознания процессапроектирования БД.Потому будем разглядывать инфологический уровень как самостоятельныйуровень представления данных. Наружный уровень в этом случае выступает какотдельный шаг проектирования, на котором изучается все внемашинноеинформационное обеспечение, другими словами формы документирования и представленияданных, также наружная среда, в какой будет работать инфы в базу данных.При проектировании БД на наружном уровне
нужно изучитьфункционирование объекта управления, для которого проектируется БД, всюпервичную и выходную документацию исходя из убеждений определения того, какие именноданные нужно сохранять в базе данных. Наружный уровень это, как правило,словесное описание входных и выходных сообщений, также данных, которыецелесообразно сохранять в БД. Описание наружного уровня не исключает наличияэлементов дублирования, избыточности и несогласованности данных. Потому дляустранения этих аномалий и противоречий наружного описания данных выполняетсяинфологическое проектирование. Инфологическая модель является средствомструктуризации предметной области и осознания концепции семантики данных.Инфологическую модель можно разглядывать в главном как средстводокументирования и структурирования формы представления информационныхпотребностей, которая обеспечивает непротиворечивое общение юзеров иразработчиков системы.Все наружные представления интегрируются на инфологическом уровне, гдеформируется инфологическая (каноническая) модель данных, которая не являетсяпростой суммой наружных представлений данных. Инфологический уровень
представляет собой информационно-логическую модель(ИЛМ) предметной области, из которой исключена избыточность данных и отображеныинформационные индивидуальности объекта управление без учета особенностей испецифики определенной СУБД. Другими словами инфологическое области, котораяотвечает особенностям и ограничениям избранной СУБД. Модель логического уровня,поддерживаемую средствами определенной СУБД, именуют еще даталогической.Инфологическая и даталогическая модели, которые показывают модель однойпредметной области, зависимы меж собой. Инфологическая модель может легкотрансформироваться в даталогическую модель. Внутренний уровень
связан с физическим размещением данных в памяти ЭВМ .На этом уровне формируется физическая модель БД, которая включает структурысохранения данных в памяти ЭВМ , в т.ч. описание форматов записей, порядок ихлогического либо физического приведения в порядок, размещение по типамустройств, также свойства и пути доступа к данным.От характеристик физической модели зависят такие свойства функционированияБД: размер памяти и время реакции системы. Физические характеристики БД можноизменять в процессе ее эксплуатации с целью увеличения эффективностифункционирование системы. Изменение физических характеристик не предопределяетнеобходимости конфигурации инфологической и даталогической моделей.Схема связи уровней представления данных в БД изображена на рис. 4.1. Всоответствии с этими уровнями проектируется БД. Проектирование БД— этосложный и трудозатратный процесс, который просит вербования многихвысококвалифицированных профессионалов. От того, как квалифицированноспроектирована БД, зависят производительность информационной системы иполнота обеспечения многофункциональных потребностей юзеров и прикладныхпрограмм. Безуспешно спроектированная БД может усложнить процесс разработкиприкладного программного обеспечения, определить необходимость использованияболее сложной логики, которая, в свою очередь, прирастит время реакциисистемы, а в предстоящем может привести к необходимости перепроектированиялогической модели БД. Реструктуризация либо внесение конфигураций в логическуюмодель БД это весьма ненужный процесс, так как он является причинойнеобходимости модификации либо даже перепрограммирование отдельных задач.Все работы, которые производятся на любом шаге проектирования, должныинтегрироваться со словарем данных. Любой шаг проектированиярассматривается как определенная последовательность итеративных процедур, врезультате которых формируется определенная модель БД. 
Рис. 4.1. и стойкость информационной модели, возможностьреализации огромного количества прикладных программ и запросов, в том численезапланированных при разработке БД. Недочетом этого подхода являетсязначительный размер работ, которые нужно выполнить при определенииинформации. подлежащей хранению в БД, что, соответственно, усложняет иувеличивает срок разработки проекта.Многофункциональный подход нацелен на реализацию текущих требованийпользователей и прикладных программ без учета перспектив развития системы.При его использовании могут появиться трудности в агрегации требованийразных юзеров и прикладных программ. Тем не наименее, при таком подходезначительно миниатюризируется трудозатратность проектирования, и потому возможносоздать систему с высочайшими эксплуатационными чертами.Но взятый в отдельности хоть какой из этих способов не может отдать достаточноинформации для проектирования рациональной структуры БД. Потому припроектировании БД целенаправлено вместе применять эти два подхода. Еслисхематично представить процесс проектирования БД на наружном уровне, то онсостоит из таковых работ.1. Определение многофункциональных задач предметной области, которыеподлежат автоматическому решению. Так как главный целью сотворения БДесть обеспечение информацией функций обработки данных, то, до этого всего,нужно изучить все функции предметной области (объекта управления), длякоторой разрабатывается база данных, и проанализировать их индивидуальности.Функции и многофункциональные индивидуальности объекта управление нужно учить внеразрывной связи с исследованием многофункциональных требований к данным со стороныбудущих юзеров информационной системы. Исследование и анализпредусматривают выявление информационных потребностей и определенияинформационных потоков. Эти работы можно делать обследованием предметнойобласти и анкетированием ее служащих. Результатом такового исследования можетбыть список многофункциональных задач, которые должны решатьсяавтоматизированным методом с внедрением БД.2. исследование и анализ оперативных первичных документов. Исследовав функции иопределив список многофункциональных задач, которые подлежат автоматизированномурешению, перебегают к исследованию оперативных документов, которые употребляются навходе каждой задачки либо их комплекса. Исследовав и проанализировав всеоперативные документы (как наружные, так и внутренние), которые используютсяна входе каждой задачки, определяют, какие реквизиты этих документов нужносохранять в БД.3. Исследование нормативно-справочных документов. На 3-ем шаге изучают ианализируют всю нормативно-справочную документацию. К таковой документациипринадлежат разные классификаторы, сметы, договоры, нормативы,законодательные акты по налоговой политике, плановая документация и т.п.Распределение и отдельный анализ оперативной и нормативно-справочнойинформации обоснованы технологически. В базы данных различаются технологиисоздания и ведения файлов условно-постоянной инфы, размещенной внормативно-справочной документации, и файлов оперативной инфы.4. исследование действий преобразования входных сообщений в выходные.До этого всего, изучаются все выходные сообщения, которые выдаются на печатьили на экран и сохраняются в виде выходных массивов на МД. Это нужно длятого, чтоб найти, которые из атрибутов входных сообщений нужносохранять в БД для получения выходных сообщений. Не считая того, на этом этапеопределяются те характеристики, которые получают во время решения задачки врезультате выполнения определенных вычислений. По любому расчетномупоказателю следует найти метод его формирования и убедиться в том,что этот показатель можно получить на базе атрибутов оперативной инормативно-справочной инфы, которые были определены на втором и третьемшагах. Если определенных данных не хватает для полного выполнения расчетов,нужно вернуться вспять, провести доп исследование иопределить, где и каким методом можно получить атрибуты, которых не хватает.Не считая того, необходимо обусловиться, какие из расчетных характеристик целесообразносохранять в БД. характеристики, приобретенные расчетным методом, как правило, в БД несохраняются. Исключением являются случаи, когда расчетный показатель нужноиспользовать для решения остальных задач либо для данной задачки, но в следующиекалендарные периоды.При проведении проектных работ на наружном уровне нужно учесть то, что длявыполнения определенных функций в БД нужно сохранять дополнительныеданные, которые не отображены в документах (данные календаря, статистическиеданные и т.п.). Обобщенная схема процесса исследования документов и данных припроектировании на наружном уровне изображена на рис. 4.2. 
Рис.4.2.
Такое исследование нужно провести по каждой многофункциональной задачке либо ихкомплексу, которые будут решаться при помощи БД.Результатом проектирования на наружном уровне будет список атрибутов(реквизитов) оперативной и условно-постоянной инфы, которые необходимохранить в БД, с указанием источников их получения и формы представления.Но этот список не исключает способности существования в немизбыточности, дублирования, несогласованности и остальных недочетов. Поэтомуна этом процесс не завершается, а осуществляется переход к этапуинфологического проектирования.]]>