Главная / Ошибки

Требования предъявляемые к бд. Связь с будущим

Аннотация: В лекции рассматривается общий смысл понятий базы данных (БД) и системы управления базами данных (СУБД). Даются основные понятия, относящиеся к базе данных такие, как алгоритм, кортеж, объект, сущность. Основные требования, предъявляемые к банку данных. Определения БД и СУБД.

Цель лекции: Уяснить разницу между базой данных и системой управления базой данных. Ознакомиться с основными требованиями, которые предъявляются к банку данных и основными определениями, относящимися к БД и СУБД.

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

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

Первое направление - применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Становление этого направления способствовало интенсификации методов численного решения сложных математических задач, развитию класса языков программирования, ориентированных на удобную запись численных алгоритмов, становлению обратной связи с разработчиками новых архитектур ЭВМ.

Второе направление, это использование средств вычислительной техники в автоматических или автоматизированных информационных системах . В самом широком смысле информационная система представляет собой программный комплекс, функции которого состоят в поддержке надежного хранения информации в памяти компьютера, выполнении специфических для данного приложения преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обычно объемы информации, с которыми приходится иметь дело таким системам, достаточно велики, а сама информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются банковские системы , системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т.д.

На самом деле, второе направление возникло несколько позже первого. Это связано с тем, что на заре вычислительной техники компьютеры обладали ограниченными возможностями в части памяти. Понятно, что можно говорить о надежном и долговременном хранении информации только при наличии запоминающих устройств, сохраняющих информацию после выключения электрического питания. Оперативная память этим свойством обычно не обладает. В начале, использовались два вида устройств внешней памяти: магнитные ленты и барабаны. При этом емкость магнитных лент была достаточно велика, но по своей физической природе они обеспечивали последовательный доступ к данным. Магнитные же барабаны (они больше всего похожи на современные магнитные диски с фиксированными головками) давали возможность произвольного доступа к данным, но были ограниченного размера.

Легко видеть, что указанные ограничения не очень существенны для чисто численных расчетов. Даже если программа должна обработать (или произвести) большой объем информации, при программировании можно продумать расположение этой информации во внешней памяти, чтобы программа работала как можно быстрее.

С другой стороны, для информационных систем, в которых потребность в текущих данных определяется пользователем, наличие только магнитных лент и барабанов неудовлетворительно. Представьте себе покупателя билета, который стоя у кассы должен дождаться полной перемотки магнитной ленты. Одним из естественных требований к таким системам является средняя быстрота выполнения операций.

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

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

Историческим шагом стал переход к использованию систем управления файлами. С точки зрения прикладной программы файл - это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Правила именования файлов, способ доступа к данным, хранящимся в файле, и структура этих данных зависят от конкретной системы управления файлами и, возможно, от типа файла. Система управления файлами берет на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса внешней памяти и обеспечение доступа к данным.

Любая задача обработки информации и принятия решений может быть представлена в виде схемы, показанной на рис. 1.1 .

Рис. 1.1.

Определение основных терминов

Дадим определения основных терминов. В качестве составных частей схемы выделяются информация (входная и выходная) и правила ее преобразования.

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

Алгоритм	- последовательность правил перехода от исходных данных к результату. Правила могут выполняться компьютером или человеком.
Данные	- совокупность объективных сведений.
Информация	- сведения, неизвестные ранее получателю информации, пополняющие его знания, подтверждающие или опровергающие положения и соответствующие убеждения. Информация носит субъективный характер и определяется уровнем знаний субъекта и степенью его восприятия. Информация извлекается субъектом из соответствующих данных.
Знания	- совокупность фактов, закономерностей и эвристических правил, с помощью которых решается поставленная задача.

Последовательность операций обработки данных называют информационной технологией (ИТ). В силу значительного количества информации в современных задачах она должна быть упорядочена. Существует два подхода к упорядочению.

Данные связаны с конкретной задачей (технология массивов) - упорядочение по использованию. Вместе с тем алгоритмы более подвижны (могут чаще меняться), чем данные. Это вызывает необходимость переупорядочения данных, которые к тому же могут повторяться в различных задачах.
В связи с этим предложена другая, широко используемая технология баз данных, представляющая собой упорядочение по хранению.

Под базой данных (БД) понимают совокупность хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений. Целью создания баз данных , как разновидности информационной технологии и формы хранения данных, является построение системы данных, не зависящих от принятых алгоритмов (программного обеспечения), применяемых технических средств и физического расположения данных в ЭВМ; обеспечивающих непротиворечивую и целостную информацию при нерегламентируемых запросах. БД предполагает многоцелевое ее использование (несколько пользователей, множество форм документов и запросов одного пользователя).

База знаний (БЗ) представляет собой совокупность БД и используемых правил, полученных от лиц, принимающих решения ( ЛПР ).

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

В настоящее время данные обрабатываются децентрализовано (на рабочих местах) с помощью персональных компьютеров (ПК). Первоначально же использовалась централизованная обработка на больших ЭВМ. В силу централизации базу данных называли банком данных и потому часто не делают различия между базами и банками данных.
Банк данных - база данных и система управления ею (СУБД). СУБД (например, FoxPro) представляет собой приложение для создания баз данных как совокупности двумерных таблиц.

Банк данных (БнД)	- это система специально организованных данных, программных, языковых, организационных и технических средств, предназначенных для централизованного накопления и коллективного многоцелевого использования данных.
Базы данных (БД)	- это именованная совокупность данных, отображающая состояние объектов и их отношения в рассматриваемой предметной области. Характерной чертой баз данных является постоянство: данные постоянно накапливаются и используются; состав и структура данных, необходимы для решения тех или иных прикладных задач, обычно постоянны и стабильны во времени; отдельные или даже все элементы данных могут меняться - но и это есть проявления постоянства - постоянная актуальность.
Система управления базами данных (СУБД)	- это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

Иногда в составе банка данных выделяют архивы. Основанием для этого является особый режим использования данных, когда только часть данных находится под оперативным управлением СУБД. Все остальные данные обычно располагаются на носителях, оперативно не управляемых СУБД. Одни и те же данные в разные моменты времени могут входить как в базы данных, так и в архивы. Банки данных могут не иметь архивов, но если они есть, то в состав банка данных может входить и система управления архивами.

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

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

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

Многократное использование данных: пользователи должны иметь возможность использовать данные различным образом.
Простота: пользователи должны иметь возможность легко узнать и понять, какие данные имеются в их распоряжении.
Легкость использования: пользователи должны иметь возможность осуществлять (процедурно) простой доступ к данным, при этом все сложности доступа к данным должны быть скрыты в самой системе управления базами данных.
Гибкость использования: обращение к данным или их поиск должны осуществляться с помощью различных методов доступа.
Быстрая обработка запросов на данные: запросы на данные должны обрабатываться с помощью высокоуровневого языка запросов , а не только прикладными программами, написанными с целью обработки конкретных запросов.
Язык взаимодействия конечных пользователей с системой должен обеспечивать конечным пользователям возможность получения данных без использования прикладных программ.

База данных - это основа для будущего наращивания прикладных программ: базы данных должны обеспечивать возможность быстрой и дешевой разработки новых приложений.

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

Организационно-методические средства - это совокупность инструкций, методических и регламентирующих материалов, описаний структуры и процедуры работы пользователя с СУБД и БД.

Пользователи БД и СУБД

Пользователей (СУБД) можно разделить на две основные категории: конечные пользователи ; администраторы баз данных .

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

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

Краткие итоги

Базы данных (БД) - это именованная совокупность данных, отображающая состояние объектов и их отношения в рассматриваемой предметной области.

Система управления базами данных (СУБД) - это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

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

Пользователей (СУБД) можно разделить на две основные категории: конечные пользователи; администраторы баз данных.

Вопросы для самопроверки

Дайте определение базы данных.
Дайте определение банка данных.
Назовите две трактовки банка данных.
Что такое система управления базой данных?
Основные требования, предъявляемые к банку данных.
Что такое данные, информация, знания?
Пользователи СУБД и БД?
Основные функции администратора БД.
Что обеспечивает возможность быстрой и дешевой разработки новых приложений?

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

Независимость данных предполагает инвариантность к характеру хранения данных, программному обеспечению и техническим средствам. Она обеспечивает минимальные изменения структуры БД при изменениях стратегии доступа к данным и структуры самих исходных данных. Это достигается, как будет показано далее, «смещением» всех изменений на этапы концептуального и логического проектирования с минимальными изменениями на этапе физического проектирования .

Безопасность данных включает их целостность и защиту.

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

Она предполагает:

1) отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;

2) защиту от ошибок при обновлении БД;

3) невозможность удаления (или каскадное удаление) связанных данных разных таблиц;

4) неискажение данных при работе в многопользовательском режиме и в распределенных базах данных;

5) сохранность данных при сбоях техники (восстановление данных).

Целостность обеспечивается триггерами целостности - специальными приложениями-программами, работающими при определенных условиях. Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться:

1) введением системы паролей;

2) получением разрешений от администратора базы данных (АБД);

4) формирование видов - таблиц, производных от исходных и предназначенных конкретным пользователям.

Три последние процедуры легко выполняются в рамках языка структуризованных запросов Structured Query Language - SQL, часто называемого SQL2.

Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).

Концепция построения БД

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

Первоначально (начало 60-х годов) использовалась файловая система хранения. Для решения преимущественно инженерных задач, характеризующихся небольшим количеством данных и значительным объемом вычислений, данные хранились непосредственно в программе. Применялся последовательный способ организации данных, имелась их высокая избыточность, идентичность логической и физической структур и полная зависимость данных. С появлением экономико-управленческих задач (информационная система руководства - MIS), отличающихся большими объемами данных и малой долей вычислений, указанная организация данных оказалась неэффективной. Требовалось упорядочение данных, которое, как выяснилось, возможно было проводить по двум критериям: использование (информационные массивы); хранение (базы данных). Первоначально применяли информационные массивы, но вскоре стало ясно превосходство баз данных. Использование файлов для хранения только данных (рис. 2.1, а) было предложено Мак Гри в 1959 году. Были разработаны методы доступа (в том числе произвольного) к таким файлам, при этом физическая и логическая структуры уже различались, а физическое расположение данных можно было менять без изменения логического представления.

В 1963 году С. Бахманом была построена первая промышленная база данных IDS с сетевой моделью данных, которая все еще характеризовалась избыточностью данных и их использованием только для одного приложения. Доступ к данным осуществлялся с помощью соответствующего программного обеспечения. В 1969 году сформировалась группа, создавшая набор стандартов CODASYL для сетевой модели данных.

Фактически начала использоваться (рис. 2.1, б) современная архитектура базы данных. Под архитектурой понимается разновидность (обобщение) структуры, в которой какой-либо элемент может быть заменен на другой элемент, характеристики входов и выходов которого идентичны первому элементу. Существенный скачок в развитии технологии баз данных дала предложенная М. Коддом в 1970 году парадигма реляционной модели данных. Под парадигмой понимается научная теория, воплощенная в систему понятий, отражающих существенные черты действительности. Теперь логические структуры могли быть получены из одних и тех же физических данных, т.е. доступ к одним и тем же физическим данным мог осуществляться различными приложениями по разным путям. Стало возможным обеспечение целостности и независимости данных.

В конце 70-х годов появились современные СУБД, обеспечивающие физическую и логическую независимость, безопасность данных, обладающие развитыми языками БД. Последнее десятилетие характеризуется появлением распределенных и объектно-ориентированных баз данных, характеристики которых определяются приложениями средств автоматизации проектирования и интеллектуализации БД.

Прежде чем рассматривать процедуры работы с базой данных, дадим набор характеристик БД (рис. 2.2)
и пояснения к нему.

Существует два подхода к построению БД, базирующихся на двух подходах к созданию автоматизированной системы управления (АСУ).

Первый из них, широко использовавшийся в 80-е годы и потому получивший название классического (традиционного), связан с автоматизацией документооборота (совокупность документов, движущихся в процессе работы предприятия). Исходными и выходными координатами являлись документы, как это видно из примера 2.1.

Пример 2.1. Задача ставится следующим образом. Имеется система ручных документов, форма одного из которых показана в табл. 2.1.

Таблица 2.1.

Данные о поставках

Необходимо с помощью БД получить - по регламенту или по запросу - информацию в виде другой системы документов, форма одного из которых приведена в табл. 2.2.

Таблица 2.2.

Отчет о поставках за квартал

Использовался следующий тезис. Данные менее подвижны, чем алгоритмы, поэтому следует создать универсальную БД, которую затем можно использовать для любого алгоритма. Однако вскоре выяснилось, что создание универсальной БД проблематично. Господствовавшая до недавнего времени концепция интеграции данных при резком увеличении их объема оказалась несостоятельной. Более того, стали появляться приложения (например, текстовые, графические редакторы), базирующиеся на широко используемых стандартных алгоритмах. Выявились стандартные алгоритмы и в управлении (бизнесе), как это следует из примера 2.2.

Пример 2.2. Рассмотрим стандартную процедуру использования банковской кредитной карточки. Покупатель-клиент выбирает товар в супермаркете и, подходя к кассе, предъявляет для оплаты кредитную карточку. Она опускается в специальный приемник, и данные с нее считываются и передаются в компьютер супермаркета. Этот компьютер связывается с компьютером банка, в котором хранятся деньги клиента. Данные из компьютера банка (относительно клиента) передаются в компьютер супермаркета. Если у клиента на счете в банке больше средств, чем стоимость отобранного им товара, то компьютер маркета разрешает отпустить товары. Одновременно он проводит пересчет средств на счете клиента, внося изменения в финансовые документы супермаркета, в счет клиента в банке и кредитную карточку. Кредитная карточка с измененными данными возвращается клиенту. Если средств у клиента недостаточно, кредитная карточка может быть возвращена клиенту и он не будет обслужен в супермаркете.

К 90-м годам сформировался второй, современный подход, связанный с автоматизацией управления. Он предполагает первоначальное выявление стандартных алгоритмов приложений (алгоритмов бизнеса в зарубежной терминологии), под которые определяются данные, а стало быть, и база данных. Объектно-ориентированное программирование только усилило значимость этого подхода. Состав БД для различных подходов представлен на рис. 2.3.

В работе БД возможен одно- и многопользовательский (несколько пользователей подключаются к одному компьютеру через разные порты) режимы.

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

В последующих разделах первоначально будет рассмотрен классический подход для централизованных БД, а затем - современный. Распределенным БД посвящена часть III настоящей работы.

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

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

Существует много разновидностей методологии рассмотрения баз данных в классическом подходе , однако чаще всего придерживаются методологии ANSI/SPARC, схема которой представлена на рис. 2.5.

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

На этапе формулирования и анализа требований устанавливаются цели организации, определяются требования к БД. Они состоят из общих требований, определенных в разделе 2.1 , и специфических требований. Для формирования специфических требований обычно используется методика интервьюирования персонала различных уровней управления. Все требования документируются в форме, доступной конечному пользователю и проектировщику БД.

Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Исходными данными могут быть совокупность документов пользователя (рис. 2.4)
при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современном подходе. Результатом этого этапа является высокоуровневое представление (в виде системы таблиц БД) информационных требований пользователей на основе различных подходов.

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

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

Специального обсуждения заслуживает процедура управления БД. Она наиболее проста в однопользовательском режиме. В многопользовательском режиме и в распределенных БД процедура сильно усложняется. При одновременном доступе нескольких пользователей без принятия специальных мер возможно нарушение целостности. Для устранения этого явления используют систему транзакций и режим блокировки таблиц или отдельных записей.

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

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

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

Средства проектирования и оценочные критерии используются на всех стадиях разработки. В настоящее время неопределенность при выборе критериев является наиболее слабым местом в проектировании БД. Это связано с трудностью описания и идентификации большого числа альтернативных решений.

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

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

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

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

Основными причинами низкой эффективности проектируемых БД могут быть:

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

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

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

Методология использования баз данных

БД используются обычно не самостоятельно, а являются компонентой различных информационных систем: банков данных, информационно-поисковых и экспертных систем, систем автоматизированного проектирования, автоматизированных рабочих мест, автоматизированных систем управления.

В БД имеется три уровня представления данных (рис. 2.4):
концептуальная, логическая и физическая базы данных.

В процедуре использования чаще всего имеют дело с логической и - значительно реже - с концептуальной и физической моделью.

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

Проектирование базы данных – это процесс создания проекта базы данных, предназначенной для поддержки функционирования экономического объекта и способствующей достижению его целей. Оно представляет собой трудоемкий процесс, требующий совместных усилий аналитиков, проектировщиков и пользователей. При проектировании базы данных необходимо учитывать тот факт, что база данных должна удовлетворять комплексу требований.

Эти требования следующие.

1. Целостность базы данных. (Требование полноты и непротиворечивости данных).

2. Многократное использование данных.

3. Быстрый поиск и получение информации по запросам пользователей.

4. Простота обновления данных.

5. Уменьшение излишней избыточности данных.

6. Защита данных от несанкционированного доступа, от искажения и уничтожения.

Жизненный цикл базы данных (ЖЦБД) – это процесс проектирования, реализации и поддержки базы данных. ЖЦБД состоит из следующих семи этапов:

1) предварительное планирование;

2) проверка осуществимости;

3) определение требований;

4) концептуальное проектирование;

5) логическое проектирование;

6) физическое проектирование;

7) оценка работы и поддержка базы данных.

Опишем главные задачи каждого этапа.

1. Предварительное планирование базы данных. Это важный этап в процессе перехода от разрозненных к интегрированным данным. На этом этапе собирается информация об используемых и находящихся в процессе разработки прикладных программах и файлах, связанных с ними. Она помогает установить связи между текущими приложениями и то, как используется информация приложений. Кроме того, позволяет определить будущие требования к базе данных.

2. Проверка осуществимости. Она предполагает подготовку отчетов по трем вопросам:

1) есть ли технология – необходимое оборудование и программное обеспечение – для реализации запланированной базы данных? (технологическая осуществимость );

2) имеются ли персонал, средства и эксперты для успешного осуществления плана создания базы данных? (операционная осуществимость );

3) окупится ли запланированная база данных? (экономическая эффективность ).

3. Определение требований .На этом этапе определяются:

· цели базы данных;

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

· требования к оборудованию;

· требования к программному обеспечению.

4.Концептуальное проектирование. На этом этапе создаются подробные модели пользовательских представлений данных предметной области. Затем они интегрируются в концептуальную модель , которая фиксирует все элементы корпоративных данных, подлежащих загрузке в базу данных. Эту модель называют еще концептуальной схемой базы данных.

5.Логическое проектирование. На этом этапе осуществляется выбор типа модели данных. Концептуальная модель отображается в логическую модель , основанную уже на структурах, характерных для выбранной модели. Так, если выбрана реляционная модель, то разрабатываются структуры таблиц, определяются их ключи, устанавливается связь между таблицами, оптимизируется созданная модель базы данных (минимизируется избыточность данных). Наиболее распространенным методом при оптимизации является метод нормальных форм или, другими словами, нормализация данных

6.Физическое проектирование. На этом этапе предусматривается принятие разработчиком окончательного решения о способах реализации создаваемой базы данных. Логическая модель расширяется характеристиками, необходимыми для определения способов физического хранения базы данных, типа устройств для хранения, методов доступа к данным базы, требуемого объема памяти, правил сопровождения базы данных и др.

7.Оценка и поддержка базы данных. Оценка включает опрос пользователей на предмет выяснения, какие их информационные потребности остались неучтенными. При необходимости в спроектированную базу данных вносятся изменения. Пользователи обучаются работе с базой данных. По мере расширения и изменения потребностей бизнеса поддержка базы данных обеспечивается путем внесения изменений, добавления новых данных, разработки новых прикладных программ, работающих с базой данных.

15. Модель «сущность–связь»

Средством моделирования предметной области на этапе концептуального проектирования является модель «сущность–связь». Часто ее называют ER-моделью (Entity – сущность, Relation – связь). В ней моделирование структуры данных предметной области базируется на использовании графических средств – ER-диаграмм (диаграмм «сущность–связь»). В наглядном виде они представляют связи между сущностями.

Основные понятия ER-диаграммы – сущность, атрибут, связь .

Сущность – это некоторый объект реального мира, который может существовать независимо . Сущность имеет экземпляры , отличающиеся друг от друга значениями атрибутов и допускающие однозначную идентификацию.

Атрибут – это свойство сущности . Например, сущность КНИГА характеризуется такими атрибутами, как автор, наименование, цена, издательство, тираж, количество страниц. Конкретные книги являются экземплярами сущности КНИГА. Они отличаются значениями указанных атрибутов и однозначно идентифицируются атрибутом «наименование». Атрибут, который уникальным образом идентифицирует экземпляры сущности, называется ключом . Может быть составной ключ, представляющий комбинацию нескольких атрибутов.

Предположим, что проектируется база данных, предназначенная для хранения информации о деятельности некоторой фирмы. Эта фирма имеет филиалы. Филиалы управляются менеджерами. Клиенты делают в филиалах заказы. Филиалы обрабатывают эти заказы. Описываемую предметную область назовем ФИРМА. В ней могут быть выделены четыре сущности: филиал, менеджер, заказ, клиент.

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

МЕНЕДЖЕР

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

В рассматриваемой предметной области ФИРМА можно выделить три связи:

1. МЕНЕДЖЕР – УПРАВЛЯЕТ – ФИЛИАЛ

2. ФИЛИАЛ – ОБРАБАТЫВАЕТ – ЗАКАЗ

3. КЛИЕНТ – ДЕЛАЕТ – ЗАКАЗ

На ER-диаграмме связь изображается ромбом.

Например,

Важной характеристикой связи является тип связи (кардинальность ).

Рассмотрим типы выше указанных связей 1–3.

Так как менеджер управляет только одним филиалом, то каждый экземпляр сущности МЕНЕДЖЕР может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 1 имеет тип «один-к-одному» (1:1). На рис. 15.1 представлена ER-диаграмма для связи типа 1:1.

Так как филиал обрабатывает несколько заказов, а заказ обрабатывается только одним филиалом, то каждый экземпляр сущности ФИЛИАЛ может быть связан более чем с одним экземпляром сущности ЗАКАЗ, а каждый экземпляр сущности ЗАКАЗ может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ.

В этом случае связь 2 имеет тип «один-ко-многим» (1:М). На рис. 15.2 представлена ER-диаграмма для связи типа 1:М.

Так как заказ могут делать несколько клиентов и клиент может иметь несколько заказов, то каждый экземпляр сущности ЗАКАЗ может быть связан с несколькими экземплярами сущности КЛИЕНТ и каждый экземпляр сущности КЛИЕНТ может быть связан с несколькими экземплярами сущности ЗАКАЗ. В этом случае связь 3 имеет тип «многие-ко-многим» (М:N). На рис. 10.3 представлена ER-диаграмма для связи типа М:N.

Рассмотрим понятие класс принадлежности сущности.

Если каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является обязательным. Этот факт отмечается на ER-диаграмме черным кружочком, помещенным в прямоугольник, смежный с прямоугольником сущности А.

Если не каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является необязательным. Этот факт отмечается на ER-диаграмме черным кружочком, помещенным на линии связи возле прямоугольника сущности А.

В качестве примера на рис. 10.4 изображены возможные ER-диаграммы для связи М:N c учетом класса принадлежности сущности.

На ER-диаграмме 1 класс принадлежности обеих сущностей необязательный.

На ER-диаграмме 2 класс принадлежности сущности КЛИЕНТ обязательный, а сущности ЗАКАЗ необязательный.

На ER-диаграмме 3 класс принадлежности сущности КЛИЕНТ необязательный, а сущности ЗАКАЗ обязательный.

На ER-диаграмме 4 класс принадлежности обеих сущностей обязательный.

Предположим, что в рассматриваемой предметной области ФИРМА класс принадлежности всех четырех сущностей является обязательным. Тогда ER-модель предметной области ФИРМА будет иметь вид, представленный на рис. 10.5.

Каждая из четырех сущностей приведенной ER-модели может быть описана своим

набором атрибутов (рис. 15.6).

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

Рис . 15.6 . Наборы атрибутов сущностей предметной области ФИРМА

Примечание. Ключевые атрибуты выделены жирным шрифтом.

КОНСПЕКТ ОБЗОРНОЙ ЛЕКЦИИ

Для студентов специальности
Т1002 «Программное обеспечение информационных технологий»

(Л.В. Рудикова, к.ф.-м.н., доцент)

Вопрос 31. АРХИТЕКТУРА СУБД. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ

1. Понятие базы данных.

2. Трехуровневая архитектура базы данных.

3. Жизненный цикл базы данных.

4. Архитектура СУБД.

5. Реляционная модель данных.

6. Проектирование реляционных баз данных.

7. Нормальные формы отношений.

8. Реляционная алгебра.

1. Понятие базы данных.

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

Информационная система – автоматическая система, организующая данные и выдающая информацию.

Информационно-управляющая система – система, обеспечивающая информационную поддержку менеджмента.

Данные – разрозненные факты.

Информация – организованные и обработанные данные.

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

Каждая СУБД должна удовлетворять следующим требованиям:

· обеспечивать пользователю возможность создавать новые БД и определять их схему (логическую структуру данных) с помощью специального языка - языка определения данных ; поддерживать разнообразные представления одних и тех же данных;

· позволять «запрашивать » данные и изменять их с помощью языка запросов , или языка манипулирования данными ; допускать интеграцию и совместное использование данных различными приложениями;

· поддерживать хранение очень больших массивов данных, измеряемых гигабайтами и более, в течение долгого времени, защищая их от случайной порчи и неавторизованного использования, а также - обеспечивать модификацию БД и доступ к данным путем запросов, т.е. гарантировать безопасность и целостность данных;

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

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

· Пользователи, т.е. люди, которые используют данные.

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

· СУБД – программное обеспечение, которое управляет доступом к данным и обеспечивает указанные функциональные возможности системы с базой данных.

· Данные, т.е. строки, хранящиеся в файлах.

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

Таким образом, систему с БД можно представить в виде следующей последовательности уровней:

На самом нижнем уровне находятся данные, хранящиеся в физических файлах (физическая память БД). На верхнем уровне – приложений с их собственными представлениями одних и тех же физических данных. Каждой представление БД – это определенная логическая структура, построенная из лежащих в основе физических данных. Чтобы обеспечить интерфейс между физической памятью БД и ее разнообразными логическими версиями (множеством поддерживаемых представлений) СУБД, в свою очередь должна состоять из нескольких уровней.

2. Трехуровневая архитектура базы данных.

Различие между логическим и физическим представлением данных официально признано в 1978 году, когда комитет ANSI / SPARC предложил обобщенную структуру систем баз данных. Эта структура получила название трехуровневой архитектуры. Три уровня архитектуры следующие: внутренний, концептуальный и внешний.

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

Концептуальный уровень – структурный уровень, определяющий логическую схему базы данных. На данном уровне выполняется концептуальное проектирование базы данных, которое включает анализинформационных потребностей пользователей и определение нужных им элементов данных. Результатом концептуального проектирования является концептуальная схема, логическое описание всех элементов данных и отношений между ними.

Внешний уровень – структурный уровень БД, определяющий пользовательские представления данных. Каждая пользовательская группа получает свое собственное представление данных в БД. Каждое такое представление данных дает ориентированное на пользователя описание элементов данных, из которых состоит представление данных, и отношений между ними. Его можно напрямую вывести из концептуальной схемы. Совокупность таких пользовательских представлений данных и дает внешний уровень.

Представления пользователей и приложений	Внешний уровень

Отображения

Концептуальная схема	Концептуальный уровень

Отображение	Внутренний уровень

Система-хост

Хранящиеся данные

Рис. Уровни СУБД

3. Жизненный цикл базы данных.

Процесс проектирования, реализации иподдержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы называется жизненным циклом системы (ЖЦС).

Понимание и правильный подход к ЖЦБД очень важен и требует детального рассмотрения, так как в его основе лежит подход, ориентированный на данные . Элементы данных более стабильны, чем выполняемые функции системы. Создание правильной структуры данных требует сложного анализа классов единиц данных и отношений между ними. Если построить логичную схему базы данных, то в дальнейшем можно создать любое количество функциональных систем, использующих эту схему. Функционально-ориентированный подход можно применять лишь для создания временных систем, которые рассчитаны на недолгое время функционирования.

ЖЦБД состоит из следующих этапов:

1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:

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

· какие файлы связаны с каждым из этих приложений;

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

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

Информация этого этапа документируется в виде обобщенной модели данных.

2. Проверка осуществимости . Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:

· технологическая осуществимость – есть ли технология для реализации запланированной БД?

· операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?

· экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

3. Определение требований включает выбор целей БД, выяснение информационных требований к системе и требований к оборудованию и программному обеспечению. Таким образом, на данном этапе сбора данных и определения требований создаётся общая информационная модель , выражающаяся в следующих задачах:

· Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.

· Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов.

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

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

4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.

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

5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.

1) Выбор и приобретение необходимой СУБД.

2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:

· на основе инфологической модели данных строится схема данных для конкретной СУБД, при необходимости реализуется денормализация БД с целью ускорения обработки запросов во всех критичных по времени приложениях;

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

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

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

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

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

· разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).

3) Построение словаря данных, который определяет хранение определений структуры данных БД. Словарь данных также содержит информацию о полномочиях доступа, правилах защиты данных и контроля данных.

4) Заполнение базы данных.

5) Создание прикладных программ, контроль управления.

6) Обучение пользователей.

6. Оценка и усовершенствование схемы БД. Включает опрос пользователей с целью выяснения функциональных неучтенных потребностей. При необходимости вносятся изменения, добавление новых программ и элементов данных по мере изменения и расширения потребностей.

Таким образом, ЖЦБД включает в себя:

· Изучение предметной области и представление соответствующей документации (1-3).

· Построение инфологической модели (4).

· Реализация (5).

· Оценка работы и поддержка БД (6).

4. Архитектура СУБД.

Рис. Главные компоненты СУБД

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

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

Менеджер памяти -получает требуемую информацию из места хранения данных и изменяет в нем информацию по требованию расположенных выше уровней системы.

В простых системах БД менеджером памяти может служить система файлов операционной системы. Однако для повышения эффективности, СУБД обычно осуществляет прямой контроль памяти. Менеджер памяти состоит из двух компонентов:

· Менеджер файлов контролирует расположение файлов на диске и получает блок или блоки, содержащие файлы, по запросу менеджера буфера (диск в общем случае делится на дисковые блоки - смежные области памяти, содержащие от 4000 до 16000 байт).

· Менеджер буфера управляет основной памятью. Он получает блоки данных с диска через менеджер файлов и выбирает страницу основной памяти для хранения конкретного блока. Он может временно сохранять дисковый блок в основной памяти, но возвращает его на диск, когда страница основной памяти нужна для другого блока. Страницы также возвращаются на диск по требованию менеджера транзакций.

Процессор «запроса» - обрабатывает запросы и запрашивает изменения данных или метаданных. Он предлагает лучший способ выполнения необходимой операции и выдает соответствующие команды менеджеру памяти.

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

Менеджер транзакций - отвечает за целостность системы и должен обеспечить одновременную обработку многих запросов, отсутствие интерференции запросов (сложение, min , max ) и защиту данных в случае выхода системы из строя. Он взаимодействует с менеджером запросов, т. к. должен знать, на какие данные воздействуют текущие запросы (для избежания конфликтных ситуаций), и может отложить некоторые запросы и операции для избежания конфликтов. Менеджер транзакций взаимодействует также с менеджером памяти, т. к. схемы защиты данных обычно включают в себя хранение файла регистрации изменений данных. При правильном порядке выполнения операции файл регистрации будет содержать запись изменений, поэтому можно заново выполнить даже те изменения, которые не достигли диска из-за сбоя в системе.

Типичные СУБД позволяют пользователю сгруппировать несколько запросов и/или изменений в одной транзакции. Транзакция - это группа операций, которые необходимо выполнить последовательно, как одно целое.

Как правило, система БД поддерживает одновременно множество транзакций. Именно правильное выполнение всех таких транзакций и обеспечивает менеджер транзакций . Правильное выполнение транзакций обеспечивается ACID -свойствами (atomicity , consistency , isolation , durability ):

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

· непротиворечивость - состояние, при котором данные соответствуют всем возможным ожиданиям (например, условие непротиворечивости для БД авиационных линий состоит в том, что ни одно из мест в самолете не бронируется для двух пассажиров);

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

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

Рассмотрим также 3 типа обращения к СУБД:

1. Запросы - вопросы по поводу данных могут генерироваться двумя способами:

a) с помощью общего интерфейса запросов (например, реляционная СУБД допускает запросы SQL , которые передаются процессору запросов, а также получает ответы на них);

б) с помощью интерфейсов прикладных программ - запросы передаются через специальный интерфейс (через этот интерфейс нельзя передавать произвольные запросы);

2. Модификации - это операции по изменению данных. Они также могут выполняться либо с помощью общего интерфейса, либо через интерфейс прикладной программы;

3. Модификации схемы - это команды администраторов БД, которые имеют право изменять схему БД или создавать новую БД.

Архитектура клиент/сервер. Во многих вариантах современного ПО реализуется архитектура клиент/сервер : один процесс (клиент) посылает запрос для выполнения другому процессу (серверу). Как правило, БД часто разделяется на процесс сервера и несколько процессов клиента.

В простейшей архитектуре клиент/сервер вся СУБД является сервером, за исключением интерфейсов запроса, которые взаимодействуют с пользователем и посылают запросы или другие команды на сервер. Например, реляционная СУБД часто использует язык SQL для представления запросов от клиента к серверу. Затем сервер БД предоставляет клиенту ответ в виде таблицы (отношения). Существует тенденция увеличения нагрузки на клиента, т. к. при наличии множества одновременно работающих пользователей БД с сервером могут возникнуть проблемы.

5. Реляционная модель данных.

РМД некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними.

Отношение представляет собой двумерную таблицу, содержащую некоторые данные. Математически под N -арным отношением R понимают множество декартова произведения D 1 D 2 … D n множеств (доменов ) D 1, D 2 , …, D n (), необязательно различных:

R D 1 D 2 … D n ,

где D 1 D 2 … D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется их своего домена.

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

· Домен имеет уникальное имя (в пределах базы данных).

· Домен определен на некотором простом типе данных или на другом домене.

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

· Домен несет определенную смысловую нагрузку .

Атрибут отношения есть пара вида <Имя_атрибута: Имя_домена>. Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов.

Отношение R , определенное на множестве доменов, содержит две части: заголовок и тело.

Заголовок отношения – это фиксированное количество атрибутов отношения:

Заголовок отношения описывает декартово произведение доменов, на котором задано отношение. Заголовок статичен, он не меняется во время работы с базой данных. Если в отношении изменены, добавлены или удалены атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем).

Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида <Имя_атрибута: Значение_атрибута>:

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

Отношение обычно записывается в виде:

или короче

или просто

Число атрибутов в отношении называют степенью (или -арностью ) отношения. Мощность множества кортежей отношения называют мощностью отношения.

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

Если атрибуты принимают значения из одного и того же домена, то они называются -сравнимыми, где – множество допустимых операций сравнений, заданных для данного домена. Например, если домен содержит числовые данные, то для него допустимы все операции сравнения, тогда . Однако, и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он имеет также полный спектр операций сравнения.

Схемы двух отношений называются эквивалентными , если они имеют одинаковую степень и возможно такое упорядочение имен атрибутов в схемах, что на одинаковых местах будут находиться сравнимые атрибуты, то есть атрибуты, принимающие значения из одного домена:

Пусть – схема отношения . – схема отношения после упорядочения имен атрибутов. Тогда

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

· Таблицы имеют одинаковое количество столбцов.

· Таблицы содержат столбцы с одинаковыми наименованиями.

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

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

Все такие таблицы есть различные изображения одного и того же отношения.

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

· В отношении нет одинаковых кортежей .

· Кортежи не упорядочены (сверху вниз) .

· Атрибуты не упорядочены (слева направо) .

· Все значения атрибутов атомарны .

Рис. Схематическое изображение отношения

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

6. Проектирование реляционных баз данных.

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

1) С учетом семантики предметной области необходимо наилучшим способом представить объекты предметной области в виде абстрактной модели данных (даталогическое проектирование). Т.е. - определиться со схемой БД: из каких отношений должны состоять БД, какие атрибуты должны быть у этих отношений, каковы связи между отношениями.

2) Обеспечить эффективность выполнения запросов к базе данных (физическое проектирование БД).

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

· Построение корректной схемы данных ориентируясь на реляционную модель данных.

· Описание схемы БД в терминах выбранной СУБД.

· Описание внешних моделей в терминах выбранной СУБД.

· Описание декларативных правил поддержки целостности БД.

· Разработка процедур поддержки семантической целостности БД.

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

Корректной называется схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений. Процесс разработки корректной схемы БД называется логическим проектированием .

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

· Метод декомпозиции (разбиения) – исходное множество отношений, входящих в схему БД заменяется другим множеством отношений, являющихся проекциями исходных отношений! При этом число отношений возрастает.

· Метод синтеза – компоновка схемы БД из заданных исходных элементарных зависимостей между объектами предметной области.

Классическое проектирование БД связано с теорией нормализацией , которая основана на анализе функциональных зависимостей между атрибутами отношений. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области.

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

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

В теории реляционных БД обычно выделяют следующие нормальные формы:

первая нормальная форма (1 NF );

· вторая нормальная форма (2 NF );

· третья нормальная форма (3 NF );

· нормальная форма Байса-Кодда (BCNF );

· четвертая нормальная форма (4 NF );

· пятая нормальная форма или форма проекции - соединения (5 NF или PYNF ).

Основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

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

7. Нормальные формы отношений.

В основе процесса нормализации лежит адекватное отражение предметной области в виде таблиц, содержащих данные о моделируемом объекте, и возможность изменения состояния базы данных с течением времени. Как правило, из-за несоответствия модели данных предметной области могут возникнуть аномалии, которые проявляются при выполнении соответствующих операций:

· Аномалии вставки (INSERT) – хранение в одном отношении разнородной информации.

· Аномалии обновления (UPDATE) –избыточность данных отношения из-за хранения разнородной.

· Аномалии удаления (DELETE) – хранение разнородной информации в одном отношении.

Следует учитывать также возникающие неопределенные ( NULL ) значения . В разных СУБД при выполнении различных операций (сравнение, объединение, сортировка, группировка и др.) два NULL -значения могут быть или не быть равными друг другу, по разному влиять на результат выполнения операций по определению средних значений и нахождения количества значений. Для исключения ошибок во многих СУБД существует возможность замены NULL -значения нулем при выполнении расчетов, объявление всех NULL -значений равными друг другу и т.п.

Нормализация – разбиение таблицы на несколько, которые обладают лучшими свойствами при обновлении, вставке и удалении данных. Т.е. нормализация представляет собой процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ, однако, на практике достаточно привести таблицы к НФБК.

Процедура нормализации основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида , где - первичный ключ, а - некоторое другое поле. Поэтому в процессе нормализации следует избавиться от всех "других" функциональных зависимостей, т.е. от тех, которые имеют иной вид, чем .

Если заменить на время нормализации коды первичных (внешних) ключей, то следует рассмотреть 2 случая:

1. Таблица имеет составной первичный ключ, например и поле , которое функционально зависит от части этого ключа, например, от (от полного ключа не зависит). Рекомендуется сформировать другую таблицу, содержащую и ( – первичный ключ), и удалить из первоначальной таблицы:

Заменить , первичный ключ , ФЗ

на , первичный ключ

и , первичный ключ .

2. Таблица имеет первичный (возможный) ключ , поле , которое не является возможным ключом, но функционально зависит от , а также – другое неключевое поле , функционально зависящее от : . Рекомендуется сформировать таблицу содержащую и ( - первичный ключ), и – удалить из первоначальной таблицы: Следует заметить, что для проведения таких операций первоначально следует иметь, в качестве входных данных некоторые «большие» (универсальные) отношения.

Опр.1. Отношение находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из его строк не содержит в любом своем поле одного значения и ни одного из ключевых полей отношения не пусто.

По опр.1, любое отношение будет находиться в 1НФ, т.е. отношение, удовлетворяющее свойствам отношений: в отношении нет одинаковых кортежей; кортежи не упорядочены; атрибуты не упорядочены и различаются по наименованию; все значения атрибутов атомарны.

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

Если потенциальный ключ является простым, то отношение автоматически находится в 2НФ.

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

Атрибуты отношения называются взаимно-независимыми , если ни один из них не является функционально зависимым от другого.

Опр.3. Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находятся в 2НФ и все неключевые атрибуты взаимно независимы (т.е. ни одно из неключевые полей отношения не зависит функционально от любого другого неключевого поля).

Чтобы устранить зависимость неключевых атрибутов, нужно произвести декомпозицию отношения на несколько отношений. При этом те неключевые атрибуты, которые являются зависимыми, выносятся в отдельное отношение.

При приведении отношений при помощи алгоритма нормализации к отношениям в 3НФ предполагается, что все отношения содержат один потенциальный ключ. Это не всегда верно. Бывают случаи, когда отношение может содержать несколько ключей.

Опр.4. Отношение находится в нормальной форме Байса-Кодда (НФБК) тогда и только тогда, когда детерминанты всех функциональных зависимостей являются потенциальными ключами (либо - если любая функциональная зависимость между его палями сводится к полной функциональной зависимости от возможного ключа).

Если отношение находится в НФБК, то оно автоматически находится в 3НФ, что следует из определения 4. Чтобы устранить зависимость от детерминантов, не являющихся потенциальными ключами, следует провести декомпозицию, вынося эти детерминанты и зависимые от них части в отдельное отношение.

Бывают случаи, когда отношение не содержит никаких функциональных зависимостей. Т.е. отношение является полностью ключевым, т.е. ключом отношения является все множество атрибутов. Т.о., мы имеем многозначную зависимость, т.к. взаимосвязь между атрибутами все-таки имеется.

Опр.5. Отношение находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда отношение находится в НФБК и не содержит нетривиальных многозначных зависимостей.

Отношения с нетривиальными многозначными зависимостями возникают, как правило, в результате естественного соединения двух отношений по общему полю, которое не является ключевым ни в одном из отношений. Реально это ведет к хранению в одном отношении информации о двух независимых сущностях.

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

Опр.6. Отношение находится в пятой нормальной форме (5НФ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной.

Опр.6. тождественно также следует определению.

Опр.7. Отношение не находится в 5НФ, если в отношении найдется нетривиальная зависимость соединения.

Т.о. если в каждой полной декомпозиции все проекции исходного отношения содержат возможный ключ, можно сделать вывод о том, что отношение находится в 5НФ. Отношение, не имеющее ни одной полной декомпозиции также находится в 5НФ.

Не зная ничего о том, какие потенциальные ключи имеются в отношении и как взаимосвязаны атрибуты, нельзя утверждать, что данное отношение находится в 5НФ или в других нормальных формах.

Возможным ключом отношения называется набор атрибутов отношения, который полностью и однозначно (функционально полно) определит значения всех остальных атрибутов отношения. В общем случае в отношении может быть несколько возможных ключей. Среди всех возможных ключей отношения как правило выбирают один, который считается главным и который называют первичным ключом отношения.

Взаимно-независимые атрибуты – это атрибуты, не зависящие один от другого. Если в отношение существует несколько ФЗ, то каждый атрибут или набор атрибутов, от которого зависит другой атрибут, называется детерминантом отношения.

9. Реляционная алгебра.

Реляционная алгебра представляет собой основу доступа к реляционным данным. Основная цель алгебры – обеспечить запись выражений. Выражения могут использоваться для:

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

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

· определение (именованных) виртуальных отношений , т.е. представление данных для их визуализации через представления;

· определение снимка, т.е. определение данных для сохранения в виде «мгновенного снимка» отношения;

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

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

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

В реализациях конкретных реляционных СУБД сейчас не используется в чистом виде ни реляционная алгебра, ни реляционное исчисление. Фактическим стандартом доступа к реляционным данным стал язык SQL (Structured Query Language).

Реляционная алгебра, определенная Коддом состоит из 8 операторов, составляющих 2 группы:

традиционные операции над множествами (объединение, пересечение, вычитание, декартово произведение);
специальные реляционные операции (выборка, проекция, соединение, деление).

Кроме того, в состав алгебры включается операция присваивания, позволяющая сохранить в базе данных результаты вычисления алгебраических выражений, и операция переименования атрибутов, дающая возможность корректно сформировать заголовок (схему) результирующего отношения.

Краткий обзор операторов реляционной алгебры.

Выборка – возвращает отношение, которое содержит все кортежи определенного отношения, удовлетворяющие некоторым условиям. Операция выборки называется также операцией ограничения (restrict - ограничение, сейчас чаще принимается выборка - SELECT ).

Проекция – возвращает отношение, содержащее все кортежи (т.е. - под кортежи) определенного отношения после исключения из него некоторых атрибутов.

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

Объединение – возвращает отношение, содержащее все кортежи, которые принадлежат или одному из двух определенных отношений, или обоим.

Пересечение – возвращает отношение, содержащее все кортежи, которые принадлежат одновременно двум определенным отношениям.

Вычитание – возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух определенных отношений и не принадлежат второму.

Соединение (естественное) – возвращает отношение, кортежи которого - это сочетание двух кортежей (принадлежащих соответственно двум определенным отношениям), имеющих общее значение для одного или нескольких общих атрибутов этих двух отношений (и такие общие значения в результирующем кортеже появляются только один раз, а не дважды).

Деление – для двух отношений, бинарного и унарного, возвращает отношение, содержащее все значения одного атрибута бинарного отношения, которые соответствуют (в другом атрибуте) всем значениям в унарном отношении.

ЛИТЕРАТУРА

1. Дейт К.Дж. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2000. – 848 с.

2. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2000. – 1120 с.

3. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.

4. Фаронов В.В., Шумаков П.В. Delphi 4. Руководство разработчика баз данных. – М.: «Нолидж», 1999. – 560 с.

5. Дж. Грофф, П.Вайнберг. SQL: Полное руководство: Пер. с англ. – К.: Издательская группа BHV, 2001. – 816 с.

6. Кен Гетц, Пол Литвин, Майк Гилберт. Access 2000. Руководство разработчика. Т.1, 2. Пер. с англ. – К.: Издательская группа BHV, 2000. – 1264 с, 912 c.

7. Маклаков С.В BPwin и EPwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001. – 304 с.

8. Ульман Д., Уидом Д. Введение в системы баз данных / Пер. с англ. – М.: «Лори», 2000. – 374 с.

9. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д.Хомоненко. – Спб.: КОРОНА принт, 2000. – 416 с.

Развитие технологий баз данных определяется рядом факторов: ростом информационных потребностей пользователей, требованиями эффективного доступа к информации, появлением новых видов машиной памяти и увеличением ее емкости, новыми средствами и возможностями в сфере телекоммуникаций и др.

К современным базам данных предъявляются следующие основные требования:

1. Высокое быстродействие (малое время отклика на запрос). Время отклика - промежуток времени от момента запроса к БД до фактического получения данных. Похожим является термин время доступа - промежуток времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом понимается операция поиска, чтения данных или записи их. Часто операции записи, удаления и модификации данных называют операциями обновления.

2. Простота обновления данных. Важнейшими являются эти первые два противоречивых требования: повышение быстродействия требует упрощения структуры БД, что, в свою очередь, затрудняет процедуру обновления данных, увеличивает их избыточность

3. Независимость данных - возможность изменения логической и физической структуры БД без изменения представлений пользователей. Независимость данных предполагает инвариантность к характеру хранения данных, программному обеспечению и техническим средствам. Она обеспечивает минимальные изменения структуры БД при изменениях стратегии доступа к данным и структуры самих исходных данных. Это достигается, как будет показано далее, «смещением» всех изменений на этапы концептуального и логического проектирования с минимальными изменениями на этапе физического проектирования

4. Совместное использование данных многими пользователями.

5. Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения. Безопасность данных включает их целостность и защиту. Целостность данных - устойчивость хранимых данных к разрушению и уничтожению, связанных с неисправностями технических средств, системными ошибками и ошибочными действиями пользователей. Целостность данных предполагает:

1) отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;

2) защиту от ошибок при обновлении БД;

3) невозможность удаления (или каскадное удаление) связанных данных разных таблиц;

4) неискажение данных при работе в многопользовательском режиме и в распределенных базах данных;

5) сохранность данных при сбоях техники (восстановление данных).

Для обеспечения целостности БД накладывают ограничения целостности в виде некоторых условий, которым должны удовлетворять хранимые в базе данные (например, диапазон значений атрибутов и др.):

Целостности сущностей - любой кортеж любого отношения отличим от любого другого кортежа этого отношения

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

1) введением системы паролей;

2) получением разрешений от администратора базы данных (АБД);

4) формирование видов - таблиц, производных от исходных и предназначенных конкретным пользователям.

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

6. Стандартизация построения и эксплуатации БД (фактически СУБД). Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).

7. Минимальная избыточность – любой элемент данных должен храниться в единственном экземпляре.

8. Многократное использование данных.

9. Однократный ввод данных.

11. Дружелюбный интерфейс пользователя.

Конец работы -

Эта тема принадлежит разделу:

Информационные технологии

Международный институт трудовых и социальных отношений.. Витебский филиал.. Кафедра экономики и менеджмента..

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

Что будем делать с полученным материалом:

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

Все темы данного раздела:

Курс лекций
Для студентов специальности «Менеджмент» (часть вторая) Витебск, 2010 Печатается по решению научно-методического совета ВФ УО ФПБ МИТСО

Экономическая информация в автоматизированных информационных системах. Организация хранения данных
План Экономическая информация. Виды и структурные единицы экономической информации. Экономические информационные системы (ЭИС). Внемашинная организа

Внемашинная организация ЭИ
Внемашинная организация экономической информации включает в себя систему классификации и кодирования информации; системы управленческой документации; систему организации, хранения, внесения изменен

Основные этапы проектирования БД
Проектирование – процесс создания описаний новой системы, которая способна функционировать. В процессе проектирования базы данных выделяют 3 этапа: 1. концептуальное проектирование – созда

Определение объектов
Выделим следующие объекты: 1. ТОВАР - (Т); 2. ЗАКАЗЧИК - (З); 3. ПОСТАВЩИК - (П); 4. СЧЕТА - (С

Системы управления базами данных
План 1. Основные понятия. Классификация СУБД. 2. Функциональные возможности СУБД Режимы работы пользователя с СУБД. Направления развития СУБД

Функциональные возможности СУБД
Это возможности по созданию базы данных и ее актуализации, извлечению данных, созданию приложений базы данных, взаимодействию с другими системами, управлению базой данных. В настоящее врем

Режимы работы пользователя с СУБД. Направления развития СУБД
СУБД предполагает работу пользователя с базой в различных режимах: Ø режим «ассистента» - используется разветвленное меню, не требуется специальной подготовки пользователя;

Структура команды
<имя оператора><ключевое слово> <дополнит. ключевые слова, константы, выражения > Приме

Связывание таблиц
С помощью языка SQL можно создавать запросы, позволяющие извлечь данные из нескольких таблиц. Одна из возможностей сделать это заключается в связывании таблиц по одному или нескольким полям. Обрати

Ключевые слова Аll и DISTINCT
До этого момента мы рассматривали, как извлечь все или заданные колонки из одной или нескольких таблиц. Для управления выводом дублирующихся строк результирующего набора данных можно использовать к

Модификация метаданных
Существуют несколько операторов SQL для управления метаданными, которые используются для создания, изменения или удаления баз данных и содержащихся в них объектов (таблиц, представлений и др.). Мы

Представления, триггеры и хранимые процедуры
Для большинства современных серверных СУБД характерны дополнительные объекты - представления, триггеры и хранимые процедуры. Представления также поддерживаются и многими настольными СУБД, например

Работа SQL со множеством пользователей
Транзакция (transaction) - это группа операций над данными, которые либо выполняются все, либо все вместе отменяются. Сердцевиной и основой эффективности функционирования многопользовательских сист

Системы удаленной обработки данных
В работе с БД возможен одно- и многопользовательский (несколько пользователей подключаются к одному компьютеру) режимы. По технологии обработки данных базы данных подразде

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

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

Методы защиты БД
Одной из оборотных сторон компьютерных информационных технологий является обострение проблемы защиты информации. Данные в компьютерной форме сосредоточивают в физически локальном и небольшом

Резервирование и восстановление БД
В ряде приложений сохранность и работоспособность базы данных является чрезвычайно критическим аспектом либо в силу технологических особенностей (системы реального вре

Оптимизация работы БД
У каждого производителя базы данных есть целый раздел в документации, который посвящен вопросам производительности и оптимизации работы базы данных. Надо понимать, что типовая поставка базы данных

Правовая охрана баз данных
1. Закон РБ«Об авторском праве и смежных правах»от 16.05.1996 (ред. 2004 г.) – Статья 6 – объектами авторского права являются БД. 2. «Концепция формирования национальной б

Понятие искусственного интеллекта
«Интеллект – совокупность всех познавательных функций индивида: от ощущений и восприятия до мышления и воображения; в более узком смысле – мышление. И. – основная форма познания че

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

Понятие экспертной системы
Наиболее широкое применение методы ИИ нашли в программах, названных экспертными системами. В них накапливается опыт специалистов в узкой предметной области. Затем при помощи знаний, накопленных в Э

Особенности предметной области как объекта автоматизации
Для многих предприятий сегодня актуальны проблемы повышения эффективности управления предприятием, для разрешения которых необходимо повышение эффективности бизнес-процессов, снижение издержек, опт

Автоматизированные системы обработки информации в промышленной сфере
Различают системы автоматического управления (САУ) и автоматизированные системы управления(АСУ).

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

Основы проектирования компьютерных информационных технологий
План 1. Жизненный цикл информационной системы. 2. Каноническое и индустриальное проектирование информационной системы. 3. Реинжиниринг бизнес-процессов.

Каноническое и индустриальное проектирование информационной системы
Каноническое проектированиеИС предполагает создание индивидуального проекта по заданию заказчика.На сегодняшний день технологию канонического проектирования исполь

Реинжиниринг бизнес-процессов
Инжиниринг представляет собой приемы и методы, используемые для проектирования новых структур и процессов в соответствии с их целями и задачами. В настоящее время нет единого поняти