Проектирование баз и хранилищ данных

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

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

широко используемых на практике СУБД семьи dBASE применяется единый язык

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

физическом уровнях. Этот язык имеет свой синтаксис: например, имя файла не

должно превышать восьми символов, а имя поля - десяти; при этом каждое имя

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

(DATA), символьные поля — С (CHARACTER), числовые — N (NUMERIC), логические

— L (LOGICAL), примечаний — М (MEMO).

Описание всех имен, типов и размеров полей сохраняется в памяти вместе

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

исправить. Если логический и физический уровни отделены, то в состав СУБД

может входить язык описания сохранения данных. В некоторых СУБД

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

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

прикладной программы. В составе СУБД типа dBASE такой язык не используется.

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

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

модели БД. Этот язык не имеет ничего общего с языками программирования.

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

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

также язык графов и матриц.

Язык манипулирования данными (DML - Data Manipulation Language)

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

DML может быть базовым или автономным.

Базовый язык DML — это один из традиционных языков программирования

(BASIC, C, FORTRAN и др.). Системы, которые используют базовый язык,

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

сужает круг лиц, которые могут непосредственно обращаться к БД, поскольку

для этого нужно знать язык программирования. В таких случаях для упрощения

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

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

Автономный язык DML — это собственный язык СУБД, который дает

возможность выполнять различные операции с данными. Системы с собственным

языком называют закрытыми.

В современных СУБД для упрощения процедур поиска данных в БД

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

являются SQL и QBE.

Язык запросов SQL (Structured Query Language - структурированный язык

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

системы управления реляционными базами данных в начале 70-х годов.

Американский национальный институт стандартов (ANSI) положил этот язык в

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

организацией стандартов (ISO). Ядром существующего стандарта SQL-86,

которые часто называют SQL-2 или SQL-92, являются функции, реализованные

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

стандарт вмещает такие усовершенствования, которые некоторые разработчики

будут должны еще реализовать.

Кроме стандарта SQL-86 существует коммерческий стандарт языка SQL,

разработанный консорциумом производителей баз данных SQL Access Group. Эта

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

систем и дает возможность им «понимать» одна другую.

Был разработан стандартный интерфейс языка CLI (Common Language

Interface) для всех основных вариантов языка SQL. Этот интерфейс,

формализованный фирмой Microsoft, получил название ODBC (Open DataBase

Connectivity — открытый доступ к данным). ODBC — это интерфейс доступа к

данным, которые сохраняются под управлением разных СУБД. ODBC имеет целый

набор драйверов, с помощью которых одна СУБД может работать с данными

других систем. Архитектура ODBC изображена на рис 2.3.

[pic]

Рис. 2.3. Архитектура ODBC

Язык запросов QBE (Query By Example) — это реализация запросов по

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

заполнить предоставленную системой таблицу QBE и определить в ней критерии

поиска и выбора данных.

Пользователи банков данных

Как любой программно-организационно-технический комплекс, банк данных

существует во времени и в пространстве. Он имеет определенные стадии своего

развития:

1. Проектирование.

2. Реализация.

3. Эксплуатация.

4. Модернизация и развитие.

5. Полная реорганизация.

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

категории пользователей.

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

банка данных:

. Конечные пользователи. Это основная категория пользователей, в интересах

которых и создается банк данных, В зависимости от особенностей

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

существенно различаться. Это могут быть случайные пользователи,

обращающиеся к БД время от времени за получением некоторой информации, а

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

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

просматривающие каталог вашей продукции или услуг с обобщенным или

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

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

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

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

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

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

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

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

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

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

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

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

организацию с точки зрения одновременной работы множества конечных

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

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

развития и реорганизации эта группа пользователей отвечает за возможность

корректной реорганизации банка без изменения или прекращения его текущей

эксплуатации.

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

которая функционирует во время проектирования, создания и реорганизации

банка данных. Администраторы приложений координируют работу разработчиков

при разработке конкретного приложения или группы приложений, объединенных

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

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

приложения.

Не в каждом банке данных могут быть выделены все тины пользователей. Мы

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

настольных СУБД администратор банка данных, администратор приложении и

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

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

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

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

отделы разработчиков. Наиболее сложные обязанности возложены на группу

администратора БД.

Рассмотрим их более подробно. В составе группы администратора БД должны

быть:

. системные аналитики;

. проектировщики структур данных и внешнего по отношению к банку

данных информационного обеспечения;

. проектировщики технологических процессов обработки данных;

. системные и прикладные программисты:

. операторы и специалисты по техническому обслуживанию.

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

специалисты по маркетингу.

Основные функции группы администратора БД

1. Анализ предметной области: описание предметной области, выявление

ограничений целостности, определение статуса (доступности,

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

определение соответствия «данные - пользователь», определение

объемно-временных характеристик обработки данных.

2. Проектирование структуры БД: определение состава и структуры файлов

БД и связей между ними, выбор методов упорядочения данных и методов

доступа к информации, описание БД на языке описания данных (ЯОД).

3. Задание ограничений целостности при описании структуры БД и процедур

обработки БД:

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

предметной области;

. определение динамических ограничений целостности, присущих

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

БД;

. определение ограничений целостности, вызванных структурой БД;

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

корректировке данных;

. определение ограничений целостности при параллельной работе

пользователей в многопользовательском режиме.

4. Первоначальная загрузка и ведение БД:

. разработка технологии первоначальной загрузки БД, которая будет

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

штатном использовании базы данных;

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

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

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

между ними, и на момент начала штатной эксплуатации эта модель

должна полностью соответствовать состоянию объектов предметной

области на данный момент времени;

. в соответствии с разработанной технологией первоначальной

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

первоначального ввода данных.

5. Защита данных:

. определение системы паролей, принципов регистрации

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

одинаковыми правами доступа к данным;

. разработка принципов защиты конкретных данных и объектов

проектирования;

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

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

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

системы зашиты;

. тестирование системы защиты;

. исследование случаев нарушения системы защиты и развитие

динамических методов защиты информации в БД.

6. Обеспечение восстановления БД:

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

восстановления БД;

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

процессов восстановления БД после сбоев.

7. Анализ обращений пользователей БД: сбор статистики по характеру

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

8. Анализ эффективности функционирования БД:

. анализ показателей функционирования БД;

. планирование реструктуризации (изменение структуры) БД и

реорганизации БнД.

9. Работа с конечными пользователями:

. сбор информации об изменении предметной области;

. сбор информации об оценке работы БД;

. обучение пользователей, консультирование пользователей;

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

работе конечных пользователей.

10. Подготовка и поддержание системных средств:

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

возможности и необходимости их использования в рамках БД;

. разработка требуемых организационных и программно-технических

мероприятий по развитию БД;

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

подключением их к БД;

. курирование подключения новых программных средств к БД.

11. Организационно-методическая работа по проектированию БД:

. выбор или создание методики проектирования БД;

. определение целей и направления развития системы в целом;

. планирование этапов развития БД;

. разработка общих словарей-справочников проекта БД и

концептуальной модели;

. стыковка внешних моделей разрабатываемых приложений;

. курирование подключения нового приложения к действующей БД;

. обеспечение возможности комплексной отладки множества

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

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

Терминология в СУБД, да и сами термины «база данных» и «банк данных»

частично заимствованы из финансовой деятельности. Это заимствование — не

случайно и объясняется тем, что работа с информацией и pa6oтa с денежными

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

объекта обработки: две банкноты достоинством в сто рублей столь же

неотличимы и взаимозаменяемы, как два одинаковых байта (естественно, за

исключением серийных номеров). Вы можете положить деньги на некоторый счет

и предоставить возможность вашим родственникам или коллегам использовать их

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

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

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

когда клали их на ваш счет.

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

быть устроена СУБД, предлагались различные способы реализации. Самым

жизнеспособным из них оказалась предложенная американским комитетом по

стандартизации ANSI (American National Standards Institute) трехуровневая

система организации БД, изображенная на рис. 2.1:

[pic]

Рис. 2.1. Трехуровневая модель системы управления базой данных,

предложенная ANSI

1. Уровень внешних моделей — самый верхний уровень, где каждая модель

имеет свое «видение» данных. Этот уровень определяет точку зрения на

БД отдельных приложений. Каждое приложение видит и обрабатывает

только те данные, которые необходимы именно этому приложению.

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

квалификации сотрудника, но ее не интересуют сведения об окладе,

домашнем адресе и телефоне сотрудника, и наоборот, именно эти

сведения используются в подсистеме отдела кадров.

2. Концептуальный уровень — центральное управляющее звено, здесь база

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

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

данных. Фактически концептуальный уровень отражает обобщенную модель

предметной области (объектов реального мира), для которой

создавалась база данных. Как любая модель, концептуальная модель

отражает только существенные, с точки зрения обработки, особенности

объектов реального мира.

3. Физический уровень — собственно данные, расположенные в файлах или в

страничных структурах, расположенных на внешних носителях

информации.

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2)

и физическую (между уровнями 2 и 3) независимость при работе с данными.

Логическая независимость предполагает возможность изменения одного

приложения без корректировки других приложений, работающих с этой же базой

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

информации с одних носителей на другие при сохранении работоспособности

всех приложений, работающих с данной базой данных. Это именно то, чего не

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

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

Классификация банков данных

Банки данных — это очень сложная система, которую можно

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

так и отдельных его компонентов.

По назначению БнД бывают:

- информационно-поисковые;

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

- банки данных АСУ для организационно-экономической информации;

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

производственных испытаний;

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

По архитектуре поддерживаемой вычислительной среды БнД бывают

централизованными (интегрированными) и распределенными.

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

банки документов и банки знаний.

По языку общения пользователя с БД различают системы с базовым языком

(открытые системы) и с собственным языком (закрытые системы).

В открытых системах языковым средством общения с БД один из языков

программирования, например C, Pascal. В таких системах для общения с БД

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

программирования.

Закрытые системы имеют собственный язык общения. Он, как правило,

намного проще, чем язык программирования. Поэтому в таких системах не нужен

посредник-программист для общения с БД. Сами пользователи, которые имеют

соответствующую подготовку, смогут работать с БД.

Одними из основополагающих в концепции баз данных являются обобщенные

категории «данные» и «модель данных».

Понятие «данные» в концепции баз данных — это набор конкретных

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

другие факторы. Примеры данных: Петров Николай Степанович, $30 и т. д.

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

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

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

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

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

различиями, но, тем не менее, можно выделить нечто общее в этих

определениях-

Модель данных — это некоторая абстракция, которая, будучи приложима к

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

уже как информацию, то есть сведения, содержащие не только данные, но и

взаимосвязь между ними.

[pic]

Рис. 2.4. Классификация моделей данных

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

В соответствии с рассмотренной ранее трехуровневой архитектурой мы

сталкиваемся с понятием модели данных по отношению к каждому уровню. И

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

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

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

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

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

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

методы хеширования, взаимосвязанных файлов. Кроме того, современные СУБД

широко используют страничную организацию данных. Физические модели данных,

основанные на страничной организации, являются наиболее перспективными.

Наибольший интерес вызывают модели данных, используемые на

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

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

модели данных.

Кроме трех рассмотренных уровней абстракции при проектировании БД

существует еще один уровень, предшествующий им. Модель этого уровня должна

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

используемой СУБД. Эти модели называются инфологическими, или

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

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

абстрагирования, связанный с фиксацией и описанием объектов предметной

области, их свойств и их взаимосвязей.

Инфологические модели данных используются на ранних стадиях

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

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

Документальные модели данных соответствуют представлению о

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

форматы документов, текстов на естественном языке.

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

всего, со стандартным общим языком разметки — SGML (Standard Generalized

Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х

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

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

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

осуществляется при помощи специального набора правил, называемых DTD-

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

Для каждого класса документов определяется свой набор правил, описывающих

грамматику соответствующего языка разметки. С помощью SGML можно описывать

структурированные данные, организовывать информацию, содержащуюся в

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

формате. Но ввиду некоторой своей сложности SGML использовался в основном

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

является HTML), и немногие приложения работали с SGML-документами напрямую.

Гораздо более простой и удобный, чем SGML, язык HTML позволяет

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

инструкций — тегов, при помощи которых осуществляется процесс разметки.

Инструкции HTML в первую очередь предназначены для управления процессом

вывода содержимого документа на экране программы-клиента и определяют этим

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

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

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

протокола HTTP. Эта особенность, а также то, что HTML является открытым

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

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

повлияли на рост популярности HTML и сделали его сегодня главным механизмом

представления информации в Internet.

Однако HTML сегодня уже не удовлетворяет в полной мере требованиям,

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

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

одновременно с этим, удобный язык XML. В чем же заключаются его

достоинства?

XML (Extensible Markup Language) — это язык разметки, описывающий целый

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

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

правильностью составления документов. То есть сам по себе XML не содержит

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

их создания.

Тезаурусные модели основаны на принципе организации словарей, содержат

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

грамматике. Эти модели эффективно используются в системах-переводчиках,

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

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

Дескрипторные модели — самые простые из документальных моделей, они

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

данных. В этих моделях каждому документу соответствовал дескриптор —

описатель. Этот дескриптор имел жесткую структуру и описывал документ в

соответствии с теми характеристиками, которые требуются для работы с

документами в разрабатываемой документальной БД. Например, для БД,

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

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

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

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

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

тексту патента.

Глава 3. Проектирование баз данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

логического (даталогического) и внутреннего.

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

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

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

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

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

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

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

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

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

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

В соответствии с этой концепцией внешний уровень это часть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

информационных потребностей, которая обеспечивает непротиворечивое общение

пользователей и разработчиков системы.

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

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

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

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

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

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

особенностей и специфики конкретной СУБД. То есть инфологическое

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

проектирует или использует базу данных.

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

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

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

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

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

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

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

называют еще даталогической.

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

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

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

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

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

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

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

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

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

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

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

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

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

моделей.

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

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

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

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

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

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

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

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

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

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

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

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

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

перепрограммирование отдельных задач.

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

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

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

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

[pic]

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

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

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

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

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

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

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

помощью БнД.

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

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

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

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

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

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

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

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

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

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

управление.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

предметной области и анкетированием ее сотрудников. Результатом

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

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

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

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

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

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

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

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

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

в БД.

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

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

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

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

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

нормативно-справочной информации обусловлены технологически. В базы

данных различаются технологии создания и ведения файлов условно-

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

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

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

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

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

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

входных сообщений нужно сохранять в БД для получения выходных

сообщений. Кроме того, на этом этапе определяются те показатели,

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

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

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

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

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

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

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

дополнительное исследование и определить, где и каким способом можно

получить атрибуты, которых не хватает.

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

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

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

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

задачи, но в следующие календарные периоды.

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

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

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

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

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

изображена на рис. 4.2.

[pic]

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

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

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

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

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

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

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

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

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

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

Составные части инфологической модели

Основными составными элементами инфологической модели являются сущности

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

Сущность – любой различимый объект (объект, который мы можем отличить

от другого), информацию о котором необходимо хранить в базе данных.

Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д.

Необходимо различать такие понятия, как тип сущности и экземпляр сущности.

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

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

конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а

экземпляром – Москва, Киев и т.д.

Атрибут – поименованная характеристика сущности. Его наименование

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

одинаковым для различного типа сущностей (например, ЦВЕТ может быть

определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты

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

сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА,

НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и

экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений:

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

сущности присваивается только одно значение атрибута.

Абсолютное различие между типами сущностей и атрибутами отсутствует.

Атрибут является таковым только в связи с типом сущности. В другом

контексте атрибут может выступать как самостоятельная сущность. Например,

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

а для лакокрасочной фабрики цвет – тип сущности.

Ключ – минимальный набор атрибутов, по значениям которых можно

однозначно найти требуемый экземпляр сущности. Минимальность означает, что

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

по оставшимся. Для сущности Расписание ключом является атрибут Номер_рейса

или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии,

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

Связь – ассоциирование двух или более сущностей. Если бы назначением

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

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

основных требований к организации базы данных – это обеспечение возможности

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

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

нередко содержатся сотни или даже тысячи сущностей, то теоретически между

ними может быть установлено более миллиона связей. Наличие такого множества

связей и определяет сложность инфологических моделей.

Требования и подходы к инфологическому проектированию

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

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

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

модель (ИЛМ), которая должна отвечать таким требованиям:

- обеспечение наиболее естественных для человека способов сбора и

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

создаваемой базе данных;

- корректность схемы БД, то есть адекватное отображение моделированной

ПО;

- простота и удобство использования на следующих этапах

проектирования, то есть ИЛМ может легко отображаться на модели БД,

которые поддерживаются известными СУБД (сетевые, иерархические,

реляционные и др.);

- ИЛМ должна быть описана языком, понятным проектировщикам БД,

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

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

(информационных объектов ПО), которые подлежат хранению в БД, а также в

определении характеристик (атрибутов) объектов и взаимосвязей между ними.

Существует два подхода к инфологическому проектированию: анализ

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

объектов, называется нисходящим, а на синтезе атрибутов — восходящим.

Страницы: 1, 2