6.2. Проектирование Баз данных
реклама
Использование системы управления базами данных для выполнения учебных заданий из различных предметных областей. План лекции 6.1. Информационные Базы и Банки данных, их особенности 6.2. Проектирование Баз данных 6.3. Модели организации данных в Базе данных 6.4. Структура системы управления Базами данных 6.5. Применение системы управления Базами данных в управлении предприятием 6.1. Информационные Базы и Банки данных, их особенности Ведущим направлением в организации внутримашинного информационного обеспечения является технология Баз и Банков данных. База данных – это специальным образом организованное хранилище информационных ресурсов в виде интегрированной совокупности файлов, обеспечивающее удобное взаимодействие между ними и быстрый доступ к данным. База данных представляет собой управляемую совокупность данных, являющихся исходной информацией для решения задач системы управления и принятия управляющих решений, может включать информацию для всех задач или групп задач. Система управления базой данных представляет собой совокупность языковых и программных средств, обеспечивающих формирование и введение массивов данных. Обработка и выдача необходимой информации для коллектива пользователей или задач управления реализуется посредством программ управления информационной базой. Банк данных – это автоматизированная система, представляющая совокупность информационных, программных, технических средств и персонала, обеспечивающих хранение, накопление, обновление, поиск и выдачу данных. Организационная структура Банка данных включает: Базу данных; систему управления базой данных; архив и система управления архивом; языковые средства (языки программирования, языки запросов и ответов, языки описания данных); методические средства (инструкции и рекомендации по созданию и функционированию Банков данных); технические средства, удовлетворяющие определенным требованиям; обслуживающий персонал, включая программистов, инженеров по техническому обслуживанию, администратора. Обслуживающий персонал должен решать следующие задачи: контроль за работой Банка данных; обеспечение совместимости и взаимодействия всех составляющих Банка Данных; управление функционированием Банка данных; контроль за качеством информации; удовлетворение информационных потребностей пользователей. Администратор с помощью специальных служебных программ управляет данными и персоналом, обслуживающим Банк данных; осуществляет защиту данных от разрушения, от несанкционированного и некомпетентного доступа, выполняет функции обеспечения надежной и эффективной работы Базы данных. Пользователями Баз и Банков данных являются специалисты, ведущие различные участки работы: главный бухгалтер, бухгалтер, операционист, начальник кредитного отдела и т. д. Они отличаются по квалификации, профессионализму и уровню в системе управления. Удовлетворение их информационных потребностей является одной из главных задач Банка Данных. Банк данных и База данных, расположенные на одном компьютере, называются локальными. Они рассчитаны на работу одного или нескольких пользователей при возможности согласования их деятельности администратором. Локальные системы Баз и Банков данных используются для организации более простого и дешевого способа обслуживания пользователей при работе с небольшими объемами информации и решении несложных задач. Они просты в эксплуатации и надежны за счет своей локальности и организационной независимости (рис. 6.1). Рис. 6.1. Локальная и распределенная система Банков и Баз данных Банк данных и База данных, расположенные на нескольких, соединенных сетями компьютерах, называются распределенными. Они используются в крупных организациях и рассчитаны на работу большого количества удаленных пользователей со значительными объемами информации в условиях географической или структурной разобщенности. Распределенные системы Баз и Банков данных обеспечивают широкие возможности в управлении сложными многоуровневыми и многозвенными объектами и процессами, так как они более гибки, адаптивны и менее чувствительны к выходу из строя оборудования. Например, при организации сети филиалов предприятия распределенная обработка данных позволяет разместить Базу данных (или несколько Баз) в узлах компьютерной сети по месту расположения филиалов. Распределение данных в организации со сложной структурой осуществляется реализацией горизонтальных и вертикальных связей между узловыми компьютерами. Использование Банков и Баз данных в информационных системах позволяет: моделировать функции управления; выполнять анализ информации для принятия управленческих решений; легко наращивать функции информационной системы; повысить качество хранимых данных за счет целостности, полноты и согласованности, за счет контроля достоверности вводимой информации и обеспечения санкционированного доступа; стандартизировать основные процедуры работы с данными (ввод, редактирование, поиск, формирование отчетов и т. д.); снизить трудозатраты на поддержку базы данных и уменьшить расход вычислительных ресурсов для хранения и эксплуатации базы данных. Основными способами организации Баз данных является создание централизованных и распределенных Баз данных.Централизованная База данных хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к Базе. Такой способ использования баз данных часто применяют в локальных сетях. Распределенная База данных состоит из нескольких, возможно пересекающихся или даже дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных. Основным критерием выбора способа организации является достижение минимальных трудовых и стоимостных затрат на проектирование структуры Базы данных, программного обеспечения системы ведения файлов, на перепроектирование Базы данных при возникновении новых задач. К организации Баз данных предъявляются следующие основные требования: логическая и физическая независимость данных; контролируемая избыточность данных; стандартизация данных за счет использования классификаторов; наличие словаря данных; специализация интерфейса для администратора и пользователя системы; контроль целостности данных; защита данных от несанкционированного доступа; наличие вспомогательных программных средств (утилит) проектирования и эксплуатации Баз данных. По способу доступа к Базе данных они подразделяются на Базы данных с локальным доступом и Базы данных с удаленным (сетевым)доступом. Системы централизованных Баз данных с сетевым доступом предполагают архитектуры: файл-сервер и клиент-сервер. Файл-сервер. Архитектура систем Баз данных с сетевым доступом предполагает выделение одной из машин сети в качестве центральной (сервер файлов). На такой машине хранится совместно используемая централизованная База данных. Все другие машины сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользовательской системы к централизованной Базе данных. Клиент-сервер. В этой концепции подразумевается, что помимо хранения централизованной Базы данных центральная машина (сервер Базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SQL. 6.2. Проектирование Баз данных Одной из наиболее трудоемких и сложных задач при создании информационных систем является проектирование Базы данных, как основы подсистемы представления и обработки данных. Организация данных требует предварительного моделирования предметной области, т. е. построения инфологической модели данных, главным назначением которой является систематизация разнообразной информации и отражение ее свойств по содержанию, структуре, объему, связям, динамике с учетом удовлетворения информационных потребностей всех категорий пользователей. Информационно-логическая (инфологическая) модель отражает предметную область в виде совокупности информационных объектов и их структурных связей. Основой для построения инфологической модели Базы данных является формализованное описание данных предметной области, которые рассматриваются как совокупность информационных объектов, содержащих наборы реквизитов и структурных связей этих объектов. Предметная область включает объекты (клиенты, счета клиентов, документы, операции и т. д.), их свойства и характеристики, взаимодействия и процессы над ними. База данных рассматривается как совокупность моделей данных, описывающих логическую структуру и физическую организацию данных на машинных носителях, находящихся под управлением СУБД. Проектирование состоит в построении комплекса взаимосвязанных моделей данных. На рис. 6.2 условно отображены этапы процесса проектирования Базы данных. Процесс проектирования Базы данных начинается с постановки задачи и выявления объектов, процессов или сущностей предметной области. Например, объектами могут быть предприятия, вкладчики, банки. Для каждого из объектов выбирается набор характеризующих его свойств (полей, реквизитов). Для предприятия – наименование, адрес, расчетный счет, название банка и пр., для вкладчика – фамилия, имя, отчество, адрес, паспортные данные, место работы и пр. Затем в процессе анализа определяется информационная потребность каждой задачи, которую составляют входные и результатные документы, и определяется периодичность решения задач. Работа проектировщиков Базы данных в значительной степени зависит от качества инфологической модели. Инфологическая модель создается для того, чтобы на ее основе можно было построить модель данных, т. е. она должна учитывать особенности реализации выбранной СУБД. На основе инфологической модели строятся концептуальная, логическая и физическая модели. Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы. Концептуальное проектирование – сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия: обследование предметной области, изучение ее информационной структуры; выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами, связями между ними и процессами; моделирование и интеграция всех представлений. Результат данного этапа – концептуальная модель, инвариантная к структуре Базы данных, часто представляется в виде модели «сущность-связь». Логическое проектирование – преобразование требований к данным в структуры данных. Результат – СУБД-ориентированная структура Базы данных и спецификации прикладных программ. На этом этапе часто моделируют Базы данных применительно к различным СУБД и проводят сравнительный анализ моделей. Физическое проектирование – определение особенностей хранения данных, методов доступа и т. д. Различие уровней представления данных на каждом этапе проектирования представлено в табл. 6.1. Физическая база данных нужна разработчикам информационной системы для разработки кода, а проектировщикам – для проверки их идей. Проектировщики и разработчики могут работать как с одной и той же схемой, так и с разными схемами. В процессе разработки проекта, как правило, создается несколько версий схемы Базы данных, поэтому обязательно ведется журнал изменений. Построение логической и физической моделей данных является основной частью проектирования Базы данных. Таблица 6.1 Различие уровней представления данных Уровень представления данных Концептуальный уровень: сущности, атрибуты, связи Логический уровень: записи, элементы данных, связи между записями Физический уровень: группировка данных, индексы, методы доступа Вид представления данных Представление аналитика Представление программиста Представление администратора Проектирование Базы данных имеет свои особенности на всех стадиях и этапах проектирования. I этап. Подготовка Технического задания (постановка задачи). Включает сбор материалов в процессе обследования и оформление Технического задания. Выполняется следующий комплекс работ: определение экономической целесообразности и технической возможности создания Базы данных; выявление состава, содержания и характеристик хранимой информации на основе результатов обследования предметной области; определение оценок, количественных характеристик информационных объектов и структурных связей между ними на основе результатов анализа информационных потребностей приложений; построение инфологической (информационно-логической) модели предметной области, определяющей совокупность информационных объектов, их атрибутов и структурных связей, динамику их изменения и характеристику информационных потребностей пользователя; предварительная оценка вариантов разработки Базы данных; оценка возможности использования СУБД и выбор СУБД. По результатам выполнения этапа создаются Технико-экономическое обоснование проектирования Базы данных (ТЭО) и Техническое задание (ТЗ). II этап. Технический проект. Результаты разработок и проектных решений оформляются в виде технического проекта. На данном этапе выполняются следующие работы: составление и уточнение инфологической модели; логическое проектирование (составление концептуальной схемы); физическое проектирование (распределение по уровням памяти, выбор методов доступа, определение размеров файлов и т. д.); проектирование и представление данных для приложений; проектирование программного обеспечения, включая СУБД. III этап. Рабочий проект. Детализуются решения технического проекта. Выполняется следующий комплекс работ: разработка программных средств и сервисных программ; настройка СУБД и приложений в соответствии с выбранными параметрами; разработка контрольного примера; разработка должностных технологических инструкций для пользователей. IV этап. Внедрение проекта (эксплуатация и отладка). Выполнятся проверка проектных решений и их доводка, при необходимости дорабатывается технология работы с Базой данных, пользователями, выполняется перераспределение обязанностей, устанавливаются категории и иерархия доступа пользователя к данным. 6.3. Модели организации данных в Базе данных Системы автоматизации Базы данных манипулируют с конкретной моделью организации данных на машинном носителе. Модель данных определяется способом организации данных, ограничениями целостности и множеством операций, допустимых над объектами организации данных. Соответственно модель данных разделяют на три составляющие: структурную, целостную и манипуляционную. При построении логической модели данных используются ниже перечисленные модели данных, поддерживаемые СУБД. К ранним (дореляционным) СУБД относятся системы, основанные на инвертированных списках, иерархические и сетевые. Эти системы исторически предшествовали реляционным системам, внутренняя организация которых во многом основана на использовании методов ранних систем. Системы, основанные на инвертированных списках. К числу наиболее известных и типичных представителей таких систем относятся Datacom/DB компании Applied Data Research, Inc. (ADR), ориентированная на использование на машинах основного класса фирмы IBM, и Adabas компании Software AG. Организация доступа к данным на основе инвертированных списков используется практически во всех современных реляционных СУБД, но в этих системах пользователи не имеют непосредственного доступа к инвертированным спискам (индексам). Структуры данных. База данных, организованная с помощью инвертированных списков, содержит хранимые таблицы, пути доступа к которым видны пользователям. Строки таблиц упорядочены системой в некоторой физической последовательности. Физическая упорядоченность строк всех таблиц может определяться и для всей Базы данных. Для каждой таблицы определяется произвольное число ключей поиска, для которых строятся индексы. Индексы автоматически поддерживаются системой, но явно видны пользователям. Иерархическая модель, имеет древовидную структуру с выраженными вертикальными связями подчинения нижнего уровня высшему уровню, что облегчает доступ к необходимой информации, но при условии, что все запросы имеют древовидную структуру. Иерархическая модель данных исторически была первой, на основе которой в конце 60-х – начале 70-х гг. ХХ в. были разработаны первые профессиональные СУБД: СУБД IMS (Information Management System) фирмы IBM, СУБД Tota, отечественные СУБД «ОКА», «ИНЭС» (рис. 6.3). Рис. 6.3. Сетевая организация данных Структура данных. База данных с иерархической моделью данных строится из упорядоченного набора экземпляров структуры типа «дерево». Тип дерева состоит из одного «корневого» типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи. Сетевая модель является расширением иерархической модели путем дополнения горизонтальных связей (рис. 6.4) Направления этих связей не являются однозначными, что усложняет модель и СУБД. Сетевая модель широко применялась в 70-е гг. ХХ в. в первых СУБД, использовавшихся крупными корпорациями для создания информационных систем: СУБД IDMS – Integrated Database Management Systemкомпании Cullinet Software Inc, СУБД IDS, предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем и отечественные СУБД «СЕТЬ», «БАНК», «СЕТОР». Архитектура системы IDMS основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол. Рис. 6.4. Сетевая организация данных В отличие от иерархической модели, в сетевой модели объектпотомок может иметь любое количество объектов-предков, поэтому допускаются любые связи-отношения, в том числе и одноуровневые. В сетевой модели выделяют следующие определения: тип записей – совокупность логически связанных элементов данных; набор типов связей между записями – отношение «один ко многим» между двумя типами записей; простая сеть – структура данных, в которой все бинарные отношения имеют отношения «один ко многим»; сложная сеть – структура данных, в которой одно или несколько бинарных отношений имеют отношения «многие ко многим»; тип записи связи – формальная запись, созданная для того, чтобы преобразовать сложную сеть в эквивалентную ей простую сеть. Сетевая СУБД состоит из одного или нескольких типов записей (типов информационных объектов) и набора типов связей между ними. Каждый тип записей представлен в Базе данных набором экземпляров записей данного типа. Аналогично каждый тип связи представлен набором экземпляров связей данного типа между конкретными экземплярами типов записей. Сетевую модель данных поддерживают СУБД dB Vista и др. Достоинства модели: более высокий уровень полноты модели, более высокий уровень равнозначности данных, сравнительно невысокие расходы на реализацию Базы данных. Недостатки: отсутствие математической теории построения модели; представление связей типа 1:1, 1:n, m:n; сложность обновления Базы данных. Реляционная модель представляется в виде совокупности таблиц, над которыми выполняются операции, формулируемые в терминах ре- ляционной алгебры (рис. 6.5). Достоинством модели является сравнительная простота инструментальных средств ее поддержки, недостатком – жесткость структуры данных и зависимость скорости работы от размера Базы данных. Рис. 6.5. Схема данных в реляционных таблицах Структура данных. Схема Базы данных (в структурном смысле) – это набор именованных схем отношений. Схема отношения – это именованное множество пар (имя атрибута, имя домена или типа, если понятие домена не поддерживается). В реляционной модели объектысущности предметной области представляются плоскими таблицами данных. Столбцы таблицы, называемые полями, соответствуют атрибутам объектов-сущностей. Множество атомарных значений атрибута называются доменом. Например, доменом для поля «Имя» является множество всех возможных имен (рис. 6.6). Строки таблицы представляющие собой различные сочетания значений полей из доменов, называются кортежами, иначе – записями, и соответствуют экземплярам объектов-сущностей. Ключевому атрибуту объекта-сущности, который идентифицирует конкретный экземпляр объекта, в таблице соответствует ключевое поле – ключ таблицы. Например, в таблице «Отделы» ключом может быть поле «Номер отдела» или поле «Наименование отдела». В тех случаях, когда конкретную запись таблицы идентифицирует значение не одного поля, а совокупность значений нескольких полей, тогда все эти поля считаются ключевыми, а ключ таблицы является составным. Например, в таблице «Сотрудники» составным ключом может быть совокупность полей «Фамилия», «Имя», «Отчество». Совокупность определенных для таблицы отношения полей, их свойства (ключи и пр.) составляют схему таблицы отношения (рис. 6.7). Значение первичного ключа уникально (не допускаются повторения), значения других полей могут повторяться. Например, в таблице «Отделы» может быть только одна запись с конкретным номером отдела, а в таблице «Сотрудники» конкретному отделу может соответствовать несколько записей сотрудников. Такой механизм обеспечивает связь типа «один ко многим» (рис. 6.7). Таблица «Отделы» Отделы № отдела 1 2 3 … Наименование отдела Плановый отдел Экономический отдел Бухгалтерия … Руководитель отдела Соболев Н.В. Тамарина Т.С. Султанова Р.С. … Количество сотрудников 7 10 10 … Таблица «Сотрудники» Сотрудники Таб. № 1 2 3 … Фамилия Соболев Блинов Суханова … Имя Отчество Николай Илья Ольга … Васильевич Ильич Петровна … Должность Начальник Зам. начальника Ст. инженер … № отдела 1 1 1 … Рис. 6.7. Связь между таблицами по типу «один ко многим» Манипулирование данными. Используется два фундаментальных механизма манипулирования реляционными Базами данных: реляционная алгебра, механизм базируется в основном на классической теории множеств; реляционное исчисление, механизм базируется на классическом логическом аппарате исчисления предикатов первого порядка. Основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных Баз данных: язык называется реляционным, если он об- ладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление. Ограничения целостности. В реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД. Первое требование называется требованием целостности сущностей. Объекту или сущности в реляционных Базах данных соответствуют кортежи отношений. Любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т. е. любое отношение должно обладать первичным ключом. Это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений. Второе требование называется требованием целостности по ссылкам. При соблюдении нормализованности отношений сложные сущности представляются в реляционной Базе данных в виде нескольких кортежей нескольких отношений. Реляционную модель данных поддерживают различные версии СУБД: dBASE, FoxBASE, R:base, Oracle, Clipper, Paradox, MS Access. Достоинства модели: наличие строгой математической теории построения модели; полнота модели; равнозначность данных; возможность представления всех типов связей от 1:1 до m:n; легкость обновления Базы данных. Недостаток: большие затраты на реализацию модели. Появление реляционных СУБД стало важным шагом вперед по сравнению с иерархическими и сетевыми СУБД, в этих системах стали использоваться непроцедурные языки манипулирования данными, и была достигнута значительная степень независимости данных от обрабатывающих программ. Именно реляционные СУБД были программным инструментарием, на основе которого происходила массовая информатизация малых и средних предприятий и организаций в 80-х гг. ХХ в. В начале 90-х гг. ХХ в. реляционные СУБД стали стандартом для построения информационных систем. В то же время выяснился ряд недостатков реляционных систем. Во-первых, сама реляционная модель ограничена в представлении данных: реляционная модель данных не допускает естественного представления данных со сложной (иерархической) структурой, поскольку в ее рамках возможно моделирование лишь с помощью плоских отношений (таблиц); все отношения принадлежат одному уровню, многие значимые связи между данными либо теряются, либо их поддержку приходится осуществлять в рамках конкретной прикладной программы; в реляционной модели поля кортежа могут содержать лишь атомарные значения; однако в системах автоматизированного проектирования, геоинформационных системах, системах искусственного интеллекта оперируют со сложными структурированными объектами. Во-вторых, имеются определенные недостатки и в реализации тех возможностей, которые прямо не предусматриваются реляционной моделью, но стали непременным атрибутом всех современных СУБД: – цикл существования реляционной базы данных состоит в переходе от одного целостного состояния к другому; однако если пользователь вводит данные, формально удовлетворяющие ограничениям целостности, но не соответствующие реальному состоянию предметной области, предыдущее «истинное» значение данных будет утеряно; – реляционная СУБД выполняет над данными не только те действия, которые задает пользователь, но и дополнительные операции в соответствии с правилами, заложенными в Базу данных. Этот механизм реализуется с помощью триггеров, однако аппарат триггеров весьма сложен в отладке и полностью не реализован ни в одной системе. Постреляционная модель данных представляет собой расширенную реляционную модель, в которой отменено требование атомарности атрибутов. Поэтому постреляционную модель называют «не первой нормальной формой» или «многомерной базой данных». Она использует трехмерные структуры, позволяя хранить в полях таблицы другие таблицы. Тем самым расширяются возможности по описанию сложных объектов реального мира. В качестве языка запросов используется расширенный SQL, позволяющий извлекать сложные объекты из одной таблицы без операций соединения. Существует несколько коммерческих постреляционных СУБД, самыми известными из них являются системы Adabas, Pick и Universe. Объектно-ориентированные модели данных. В настоящее время общепринятого определения объектно-ориентированной модели данных не существует, говорят о неком «объектном» подходе к логическому представлению данных и о различных объектноориентированных способах его реализации. Структура данных. Структура объектной модели описывается с помощью трех ключевых понятий: инкапсуляция – каждый объект обладает некоторым внутренним состоянием (хранит внутри себя запись данных), а также набором методов – процедур, с помощью которых можно получить доступ к данным, определяющим внутреннее состояние объекта, или изменить их; объекты рассматриваются как самостоятельные сущности, отделенные от внешнего мира; наследование – подразумевает возможность создавать из классов объектов новые классы объекты, которые наследуют структуру и методы своих предков, добавляя к ним черты, отражающие их собственную индивидуальность; наследование может быть простым (один предок) и множественным (несколько предков); полиморфизм – различные объекты могут по-разному реагировать на одинаковые внешние события в зависимости от того, как реализованы их методы. Манипулирования данными. В объектно-ориентированном программировании отсутствуют общие средства манипулирования данными. Работа с данными ведется с помощью одного из объектно-ориентиро- ванных языков программирования общего назначения, обычно это SmallTalk, C++ или Java. Целостность данных. Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства: – автоматическое поддержание отношений наследования; – возможность объявить некоторые поля данных и методы объекта как «скрытые», не видимые для других объектов, такие поля и методы используются только методами самого объекта; – создание процедур контроля целостности внутри объекта. Появление объектно-ориентированных СУБД вызвано потребностями программистов, которым были необходимы средства для хранения объектов, не помещавшихся в оперативной памяти компьютера. Также важна была задача сохранения состояния объектов между повторными запусками прикладной программы. Поэтому большинство СУБД представляют собой библиотеку, процедуры управления данными которой включаются в прикладную программу. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с Базой данных. Стандартным языком наиболее распространенных реляционных СУБД является язык SQL, который содержит средства SDL и DML и позволяет определять схему Базы данных и манипулировать данными. При этом именование объектов Базы данных поддерживается на языковом уровне. Компилятор SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. SQL содержит специальные средства определения ограничений целостности Базы данных, которые хранятся в специальных таблицах-каталогах. Обеспечение контроля целостности Базы данных производится на языковом уровне, т. е. при компиляции операторов модификации Базы данных компилятор SQL на основании имеющихся в Базе данных ограничений целостности генерирует соответствующий программный код. Специальные операторы SQL позволяют определять представления Базы данных – хранимые в Базе данных запросы (результатом запроса к реляционной Базе Данных является таблица) с именованными столбцами. Для пользователя представление – также таблица, хранимая в Базе данных. С помощью представлений можно ограничить или наоборот расширить видимость Базы данных для конкретного пользователя. Поддержание представлений производится на языковом уровне. Авторизация доступа к объектам Базы данных производится на основе специального набора операторов SQL. Для выполнения операторов пользователь должен обладать различными правами. Пользователь, создавший таблицу Базы данных, обладает полным набором прав для работы с этой таблицей. В их число входит полномочие на передачу всех или части полномочий другим пользователям, включая права на передачу полномочий. Права пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне. Общие требования к СУБД: использование для организации Баз данных ЭВМ, обладающих значительными ресурсами по производительности и объему памяти; применение периферийных устройств, облегчающих работу пользователей с Базой данных (сканеров, средств ввода/вывода речевой информации и др.); повышение доли выпуска многофайловых и программируемых СУБД; развитие стандартных языков запросов и манипулирования данными; совершенствование автоматизированных систем программирования, работающих в среде Баз данных под управлением СУБД; создание унифицированных интерфейсов для доступа пользователей к Базам данных из различных систем программирования, текстовых редакторов, электронных таблиц, проблемно– и методо-ориентированных прикладных пакетов. 6.4. Структура системы управления Базами данных СУБД является прикладным программным обеспечением, предназначенным для решения конкретных прикладных задач и выполнения системных функций, расширяющих возможность файловых систем системного программного обеспечения. СУБД реализует следующие функции: организацию и поддержание логической структуры данных (схемы данных), которая обеспечивается средствами модели организации данных (иерархической, сетевой, реляционной); организацию и поддержание физической структуры данных во внешней памяти, которая включает организацию и поддержание внутренней структуры файлов Базы данных, а так же создание и поддержание специальных структур (индексов, страниц) для эффективного и упорядоченного доступа к данным; организацию доступа к данным и их обработка в оперативной и внешней памяти, которая осуществляется через реализацию процессов, называемых транзакциями. В структуре СУБД в современном представлении выделяют следующие функциональные блоки. 1. Процессор описания и поддержания структуры Базы данных. Этот процессор реализует модель организации данных, средствами которой проектировщик строит логическую структуру (схему) Базы данных, соответствующую инфологической схеме предметной области и обеспечивает построение и поддержание внутренней схемы Базы данных. Процессор обеспечивает установку логической структуры Базы данных и трансляцию (перевод) структуры Базы данных во внутреннюю схему Базы данных (в физические структуры данных). 2. Процессор запросов к Базе данных. Процессор интерпретирует сформированные запросы в терминах языка манипулирования данными и совместно с процессором описания и поддержания структуры Базы данных исполняет запросы. 3. Интерфейс ввода данных СУБД. Его функция заключается в реализации входного информационного языка Банка данных, который обеспечивает абонентам-поставщикам информации средства описания и ввода данных в информационную систему. 4. Интерфейс запросов. Совместно с процессором запросов интерфейс запросов обеспечивает концептуальную модель использования информационной системы в части стандартных типовых запросов, отражающих информационные потребности пользователей-абонентов системы. 5. Мониторинг транзакций. Функции мониторинга заключаются в организации совместного выполнения транзакций от нескольких пользователей над общими данными и обеспечение целостности данных. 6. Интерфейс выдачи сведений. Процессор запросов передает результат исполнения запросов интерфейсу выдачи сведений, который переводит эти результаты в форму, удобную для восприятия и выдачи пользователю-абоненту информационной системы. 7. Генератор отчетов. Для формирования отчетов служат специальные формы выдачи. Отчеты выдают результаты поиска и отбора информации из Базы данных для формализованного создания соответствующих текстовых документов. Для выполнения данной задачи используется генератор отчетов. Основные компоненты СУБД представлены: а) средствами представления данных в Базе данных; б) средствами манипулирования данными; в) интерфейсами пользователей; г) интерфейсами администратора Базы данных; д) интерфейсами коммуникаций. Средства представления данных совместно с интерфейсами осуществляют организацию Базы данных на разных уровнях абстракции данных. Различают три уровня абстракции и представления данных: физический уровень, средства физического уровня учитывают характеристики конкретного внешнего запоминающего устройства, форматы и способы записи данных на физический носитель и др.; концептуальный уровень, средства концептуального уровня отображают данные физического уровня с определенной абстракцией; уровень определяет модель представления данных в Базе данных; внешний уровень, средства внешнего уровня преобразуют данные в форму, понятную пользователю с которой пользователь может работать через свои интерфейсы. Из вышесказанного следует, что структура СУБД представляет собой совокупность инструментальной среды создания и использования Баз данных в рамках определенной модели данных и языка СУБД (языка описания данных, манипулирования данными и средств создания интерфейса). Организация типичной СУБД и состав ее компонентов соответствуют вышеуказанному набору функций. Например, в современной реляционной СУБД логически можно выделить внутреннюю часть – ядро СУБД (Data Base Engine), компилятор языка Базы данных, подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других – нет, но логически такое разделение можно провести во всех СУБД. Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно можно выделить следующие компоненты ядра: менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором языка или в подсистеме поддержки выполнения таких программ и утилитах Базы данных. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры «клиент-сервер» ядро является основной составляющей серверной части системы. Основной функцией компилятора является компиляция операторов языка Базы данных в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем (обычно SQL) непроцедурные, т. е. в операторе языка специфицируется некоторое действие над Базой данных, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения процедуры. Поэтому компилятор должен решить, каким образом выполнить оператор языка, прежде чем произвести программу. Применяются достаточно сложные методы оптимизации операторов. Результатом компиляции является выполняемая программа, представляемая в машинных кодах или в выполняемом внутреннем машинно-независимом коде. В последнем случае выполнение оператора производится с привлечением подсистемы поддержки времени выполнения, представляющей собой интерпретатор внутреннего языка. В отдельные утилиты Базы данных выделяют процедуры, которые слишком накладно выполнять с использованием языка Базы данных, например, загрузка и выгрузка Базы данных, сбор статистики, глобальная проверка целостности Базы данных и т. д. Утилиты программиру- ются с использованием интерфейса ядра СУБД, иногда с проникновением внутрь ядра. Структура СУБД является эффективной, если она обеспечивает: ненавигационный интерфейс высокого уровня пользователя с системой, позволяющий достичь независимости данных и дать возможность пользователям работать максимально эффективно; многообразие допустимых способов использования СУБД, включая программируемые транзакции, диалоговые транзакции и генерацию отчетов; динамически изменяемую среду Баз данных, в которой отношения, индексы, представления, транзакции и другие объекты могут легко добавляться и уничтожаться без приостановки нормального функционирования системы; возможность параллельной работы с одной Базой данных многих пользователей с допущением параллельной модификации объектов Базы Данных при наличии необходимых средств защиты целостности; восстановление согласованного состояния Баз данных после сбоев аппаратуры или программного обеспечения; определение различных представлений хранимых данных, и ограничение этими представлениями доступа пользователей к Базе данных по выборке и модификации на основе механизма авторизации; производительность системы при выполнении упомянутых функций, сопоставимую с производительностью существующих СУБД низкого уровня. Очень важными компонентами СУБД являются система управления реляционной памятью (Relational Storage System, RSS) и компилятор запросов языка SQL. RSS обеспечивает интерфейс низкого уровня для доступа к данным, хранимым в Базе данных, синхронизацию транзакций, журнализацию изменений и восстановление Баз данных после сбоев. Компилятор запросов использует интерфейс RSS для доступа к справочной информации (каталогам отношений, индексов, прав доступа, условий целостности, условных воздействий и т. д.) и производит рабочие программы, выполняемые в дальнейшем с использованием интерфейса RSS. Таким образом, система разделяется на два уровня – уровень управления памятью и синхронизацией, не зависящий от базового языка запросов системы, и языковой уровень (уровень SQL), на котором решается большинство задач СУБД. 6.5. Применение системы управления Базами данных в управлении предприятием Основу деятельности управления любого экономического объекта составляют информационные системы, состав которых зависит от вида деятельности и размера организации. Системы управления базами данных являются важнейшей программной компонентой информационных систем управления предприятиями. Именно СУБД определяет мощь и эффективность той или иной информационной системы. Рассмотрим наиболее часто применяемые информационные системы и способы организации данных в них. 1. Система «Галактика». Предназначена для полной автоматизации управления в корпорациях со сложной структурой, финансово-промышленных группах, на отдельных промышленных и торговых предприятиях. Система осуществляет информационное обеспечение руководителей различных уровней и категорий – от высшего менеджмента до руководителей подразделений, служб и участков. Для крупных компаний, имеющих филиалы и территориально-удаленные подразделения, реализована возможность оперативного удаленного доступа и информационного обмена. Специфика конкретного предприятия учитывается с помощью 300 параметров настройки. Структура системы позволяет вести параллельный многоплановый учет в нескольких стандартах. Обладая средствами экономического анализа, система позволяет построить схему налогообложения и определить структуру платежей, чтобы избежать налоговых переплат и штрафов. «Галактика» – это решение для крупных и средних предприятий, комплексно в едином информационном пространстве обеспечивающее поддержку всех задач управления, включая следующие задачи: календарно-сетевое планирование; финансовое планирование; материально-техническое снабжение и сбыт (управление закупками и продажами); управление производством и проектами; управление персоналом; бухгалтерский учет; анализ производственно-хозяйственной и финансовой деятельности предприятия; анализ и планирование маркетинговых мероприятий. Поставленные задачи позволила решить интегрированная инструментальная среда моделирования, анализа, оптимизации и документирования бизнес-процедур ARIS Toolset – продукт, выпускаемый компанией IDS PROF.SCHEER GmbH (ФРГ), партнером которой в России является компания Весть-Метатехнология. Средства ARIS Toolset позволили производить анализ, оптимизацию и документирование рабочих процедур и процессов, структур данных и организационных структур, как в целостном, так и в детализированном виде. 2. Информационные системы корпорации «Парус» (используются крупнейшими государственными структурами, отечественными и зарубежными коммерческими организациями). В их число входит система «Триумф», предназначенная для автоматизации предприятий розничной торговли различных размеров и различной специализации, а также ряд информационных систем «ПАРУС». Система «Триумф» поддерживает широкий спектр торгового оборудования и гибко интегрирована с бухгалтерскими и аналитическими системами корпорации. Для работы с документами реализована трехуровневая архитектура в технологии файл-сервер – бизнес-объект, бизнес-логика, представление, а так же интеграция с MFC-архитектурой Документ – Представление. Система «Триумф» построена на основе СУБД Raima DataBase Manager. Архитектура системы OOD/OOP (Object Oriented Design & Object Oriented Programming): Raima Object Manager – объектно-ориентированная надстройка над RDM; объектно-ориентированные инструментальные классы (TDataObj, TGroupLock, TRegister); применение современных технологий проектирования (UML). Система «ПАРУС 7.11» предназначена для малых и средних хозрасчетных предприятий различной отраслевой принадлежности (торговля, сфера услуг, реклама и СМИ, общественное питание, туризм, иностранные компании и др.). Это простая, удобная система, позволяющая автоматизировать бухгалтерский учет, основные торговые процессы и складской учет. Используемые технические средства – СУБД и средство разработки – Visua FoxPro. Система «ПАРУС 8.1» (управление предприятием) предназначена для полной информационной поддержки классической модели управления предприятием. Используемые технические средства: СУБД – Oracle, среда разработки – Delphi. Программный комплекс обеспечивает автоматизацию четырех основных бизнес-направлений финансово-хозяйственной деятельности предприятия: управление финансами, логистика, управление производством и управление персоналом. Управление финансами включает следующие модули: текущее и долгосрочное финансовое планирование; оперативное планирование и управление платежами; контроль за возникновением и погашением обязательств; оперативный учет выполнения планов; анализ выполнения финансовых планов. Логистика обеспечивает учет товаров по партиям с точностью до модификаций и упаковок. В ее состав входят следующие модули: закупка; склад; реализация; розничная торговля. Управление производством включает следующие модули: производственный учет; учет затрат и калькуляцию себестоимости; технико-экономическое планирование. Управление персоналом включает: учет персонала; табельный учет рабочего времени, расчет заработной платы. Для решения общих вопросов по настройке системы и обеспечения ее функционирования в ходе работы реализован модуль Администрирования системы. Дополнительный модуль Специальные решения включает специализированные приложения для предприятий нефтяного комплекса, энергетики и электрификации и для предприятий связи. 3. Программные продукты фирм: «1С», «ДИЦ», «ИнтеллекСервис», «Инфософт» (предназначенны для автоматизации деятельности предприятия). Среди них выделяется информационная система «1С: Предприятие» (рис. 6.8), использующая универсальную специализированную объектно-ориентированную систему управления Базами данных. Система решает учетные задачи кадрового, бухгалтерского и складского учета, расчета зарплаты, учета товарных и материальных средств, учета взаиморасчетов с контрагентами, расчета амортизации основных средств и др. Контрольные вопросы 1. Дайте определение термина «База данных». 2. Дайте определение термина «Банк данных». 3. Перечислите основные способы организации Базы данных. 4. Перечислите модели организации данных в Базе данных. 5. Дайте определение термину «Системы управления Базами данных. Дать характеристику СУБД. 6. Перечислите основные функции СУБД. 7. Определите структуру СУБД. 8. Перечислите основные требования, предъявляемые к организации Баз данных. 9. Дайте определение информационно-логической модели базы данных. 10. Назовите основные этапы процесса проектирования базы данных. 11. Перечислите этапы проектирования баз данных. 12. Назовите модели данных, поддерживаемые СУБД. 13. Каковы механизмы манипулирования реляционными Базами данных. 14. Приведите ключевые понятия, описывающие структуру объектной модели. 15. Назовите общие требования, предъявляемые к СУБД. 16. Перечислите основные функции, реализуемые СУБД. 17. Назовите функциональные блоки СУБД. 18. Перечислите задачи управления, решаемые системой «Галактика».
