Базы данных

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

2. Структура и типология.

Большинство баз данных имеют табличную структуру. Как мы знаем, в табличной структуре адрес данных определяется пересечением строк и столбцов. В базах данных столбцы называются полями, а строки - записями. Поля образуют структуру базы данных, а записи составляют информацию, которая в ней содержится.
Простейшие базы можно создавать, не прибегая к специальным программным средствам. Чтобы файл считался базой данных, информация в нем должна иметь структуру (поля) и быть форматирована так, чтобы содержимое соседних полей легко различалось.
Приведем простейший пример базы данных, состоящей из одной таблицы:
№ РЕЙСА ПУНКТ_ОТПР. ПУНКТ_НАЗН. ВРЕМЯ_ВЫЛЕТА ВРЕМЯ_ПРИБЫТИЯ
83 МОСКВА С.-ПЕТЕРБУРГ 11.30 12.50
84 С.-ПЕТЕРБУРГ МОСКВА 15.00 16.15
109 МОСКВА НОВОСИБИРСК 19.50 23.22
Однако такие структуры данных самостоятельно используются крайне редко и чаще всего представляют собой отчеты баз данных ИС, сформированные по какому-либо критерию.


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


3. Архитектура организации баз данных
В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Institute) трехуровневая система организации БД, изображенная на рис

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

Внутренний  это уровень, наиболее близкий к физическому хранению, т.е.  связанный со способами сохранения информации на физических устройствах хранения.
Внешний  наиболее близок к пользователям, т.е. он связан со способами представления данных для отдельных пользователей.
Концептуальный уровень  это ;промежуточный; уровень между двумя первыми; другими словами, это центральное управляющее звено, где БД представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной БД. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась БД. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.
Внешний уровень  это индивидуальный уровень пользователя. У каждого пользователя есть свой язык общения. Все эти языки включают подъязык данных, т.е. подмножество операторов всего языка, связанное только с объектами и операциями БД.
В принципе любой подъязык данных является на самом деле комбинацией, по крайней мере двух  подчиненных языков ; языка определения данных (DDL), который поддерживает определения или объявления объектов БД, и языка обработки данных (DML), который поддерживает операции с такими объектами или их обработку.
Внешнее представление  это содержимое БД, каким видит его определенный пользователь (т.е. для этого пользователя внешнее представление и есть БД).
Концептуальное представление  это представление всей информации БД в несколько более абстрактной форме по сравнению с физическим способом хранения данных. Однако концептуальное представление существенно отличается от способа представления данных какому- либо отдельному пользователю. Концептуальное представление ; это представление данных такими, какие ;они есть на самом деле;, а не такими, какими вынужден их видеть пользователь. Концептуальная схема ; это определение такого представления. В большинстве существующих систем ;концептуальная схема; в действительности представляет собой немного больше, чем простое объединение всех отдельных внешних схем с дополнительными средствами безопасности и правилами обеспечения целостности.
Внутреннее представление  это представление нижнего уровня всей БД. Внутреннее представление так же, как внешнее и концептуальное, не связанно с физическим уровнем. Это представление предполагает бесконечное линейное адресное пространство.
Внутреннее представление описывается с помощью внутренней схемы, которая определяет не только различные типы хранимых записей, но также существующие индексы, способы представления хранимых полей, физическую последовательность хранимых записей и т.д.
Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих на этой же БД. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной БД. Это именно то, чего не хватало при использовании файловых систем.
Выделение концептуального уровня позволило разработать аппарат централизованного управления БД.

4. Понятие банка данных и функции

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

5. Структура БнД.

Рассмотрим структуру БнД и назначение основных его компонентов (рис. 1.2).
 
Рис. 1.2. Схема банка данных
Ядром БнД является база данных.
Вместе с базой данных хранится ее описание, которое относятся к метаинформации, т. е. информации об информации. Метаинформация включает в себя описание структуры БД (схемы и подсхемы), модель предметной области, информацию о пользователях и их правах, описание формы входных и выходных документов. Централизованное хранилище метаинформации называется словарем базы данных. Особенно большое значение имеют словари данных в системах автоматизированного проектирования ИС.
Пользователи не работают с базой данных непосредственно. Процесс взаимодействия между ними реализуется через СУБД. При этом возможны два варианта организации этого процесса:
; пользователь работает с СУБД в интерактивном режиме, используя систему меню;
; взаимодействие осуществляется с помощью прикладных программ, называемых приложениями.
СУБД обеспечивает безопасность и согласованность информации в базе данных. Пользователям предоставляется возможность защиты их данных от несанкционированного доступа. При аппаратных или программных сбоях СУБД должна самостоятельно восстанавливать исходное согласованное состояние базы данных.
СУБД полностью отстраняет пользователей от проблем организации хранения данных на физическом уровне.
При обращении к базе данных СУБД использует информацию, хранящуюся в ее словаре:
; логическую схему БД, описания структур хранения данных;
; сведения о допустимых значениях и форматах представления данных;
; сведения о полномочиях пользователей при работе с данными;
; характеристики физического размещения данных.
Словарь базы данных может храниться в отдельном файле или непосредственно в файле базы данных (MS Access).
Пользователей банков данных можно разделить на три большие группы.
1. Конечные пользователи. Это наиболее многочисленная группа пользователей, для обслуживания профессиональных задач которых создается конкретная база данных (менеджеры, торговые работники, финансисты и т. д.). Важно, чтобы СУБД предоставляла этой категории пользователей достаточно удобные, простые и эффективные средства работы с базой данных, не требующие от пользователей образования в области информационных технологий или длительного этапа специальных подготовки и обучения.
2. Прикладные программисты. В обязанности этой группы пользователей входит написание, отладка и внедрение прикладных программ (приложений), использующих информацию из базы данных. В основном для этого используются универсальные языки программирования: С++, Pasсal, Delphi и др.
3. Администраторы банка данных (АБД). Пользователи этой группы реализуют сложные задачи проектирования, создания, организации и поддержки работы банков данных. Администратор банка данных должен быть профессиональным специалистом в области информационных технологий и обеспечивать выполнение следующих функций:















 
6.Компоненты БнД

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

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

Языковые средства СУБД обеспечивают интерфейс пользователей разных категорий с банком данных.
Языковые средства классифицируют по разным признакам:
По поколениям:
- к первому поколению относят машинные языки,
- ко второму - символические языки Ассемблера,
- к третьему - алгоритмические языки типа PL, COBOL и т.п., которые в 60-е годы назывались языками высокого уровня, но уровень которых го¬раздо ниже, чем у языков четвертого поколения. Большинство современных СУБД относятся к языкам четвер¬того поколения
- языки пятого поколения, к которому относят языки систем искусственного интеллекта.
По функциональным возможностям:
1.   Языки, обеспечивающие только возможности запросов.
2.   Комплексные языки запросов / обновлений. Позволяют формулировать сложные запросы, относящиеся к нескольким взаимосвязанным запи¬сям, а также обновлять данные также легко, как и формулировать запросы.
3.   Генераторы отчетов. Они позволяют выбирать нужные данные из файлов или баз дан¬ных и форматировать их в виде требуемых форм документов.
4.   Графические языки. Они позволяют выводить данные в виде различных графиков и диа¬грамм, позволяют осуществлять отбор информации из файлов или баз данных по различным критериям, а также выполнять арифметические и логи¬ческие манипуляции с данными.
5.   Инструментальные средства поддержки решений. Это могут быть системы типа «что-если», системы,   выполняющие   временной   или   трендовый   анализ   и   другие.   
6. Генераторы приложений.
7.   Машино-ориентированные языки спецификаций.  Фактически являются генераторами приложений, но более универсальны и позволяют специфицировать приложения разных типов.               
8.   Языки очень высокого уровня. В большинстве случаев приложения строятся при по¬мощи непроцедурных (указывается, что нужно получить в ответе, а не как достичь) языков. Однако некоторые языки являются процедурными (указывается какие действия и над какими объектами надо выполнить, чтобы получить результат) (на¬пример, NOMAD), но программирование на них значительно короче, чем, например, на COBOLe.
9.   Параметризированные пакеты прикладных программ.  До¬пускают легкую модификацию самого пакета, позволяют пользователям генерировать собственные отчеты, запросы к базе данных и т.д.
10. Языки приложений. Спроектированы для специфических приложений. Примерами таких языков являются языки для управления финансами, управления работой станков с про¬граммным управлением и т.д.

По форме представления
-аналитические (реализуют операции реляционной алгебры, нереляционные операции, орга¬низацию циклической и условной обработки, ввод-вывод данных, корректировку, воз¬можность работы с переменными памяти и другие возможности);
- табличные (описание данных в системах представлено в табличном виде);
 - графические языковые средства.
Например, СУБД  Access, FoxPro используют языки запросов табличного типа не только для непосредственной реализации запросов, но и как средство для более простого описания запроса и последующего автоматического преобразования его на язык SQL.
Технические средства:
- ЭВМ;
- средства хранения данных;
- средства отображения данных;
- коммуникационные средства.

Тип используемой ЭВМ зависит от масштаба создаваемой системы.

7. Общая классификация моделей данных.

Модель данных — это некоторая абстракция, которая, будучи применена к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними.
Более точное определение понятия «модель данных» в рамках теории баз данных представлено ниже:
Организация данных и способы доступа к ним, обеспечиваемые конкретной СУБД, называются моделью данных.
На рис. 2.1 представлена классификация моделей данных.
 
Наибольший интерес вызывают модели данных, используемые на концептуальном уровне. По отношению к ним внешние модели называются подсхемами и используют те же абстрактные категории, что и концептуальные модели данных.
Кроме трех рассмотренных уровней абстракции при проектировании БД существует еще один уровень, предшествующий им. Модель этого уровня должна выражать информацию о предметной области в виде, независимом от используемой СУБД. Эти модели называются инфологическими, или семантическими, и отражают в естественной и удобной для разработчиков и других пользователей форме информационно-логический уровень абстрагирования, связанный с фиксацией и описанием объектов предметной области, их свойств и их взаимосвязей.
Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложения, а даталогические модели уже поддерживаются конкретной СУБД.
Документальные модели данных соответствуют представлению о слабоструктурированной информации, ориентированной в основном на свободные форматы документов, текстов на естественном языке.
Модели, основанные на языках разметки документов, связаны прежде всего со стандартным общим языком разметки — SGML (Standart Generalised Markup Language), который был утвержден ISO в качестве стандарта еще в 80 х годах. Этот язык предназначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, называемых DTD-описаниями, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки. С помощью SGML можно описывать структурированные данные, организовывать информацию, содержащуюся в документах, представлять эту информацию в некотором стандартизованном формате. Но ввиду некоторой своей сложности SGML использовался в основном для описания синтаксиса других языков (наиболее известным из которых является HTML), и немногие приложения работали с SGML-документами напрямую.
Гораздо более простой и удобный, чем SGML, язык HTML позволяет определять оформление элементов документа и имеет некий ограниченный набор инструкций — тегов, при помощи которых осуществляется процесс разметки. Инструкции HTML в первую очередь предназначены для управления процессом вывода содержимого документа на экране программы-клиента и определяют этим самым способ представления документа, но не его структуру. В качестве элемента гипертекстовой базы данных, описываемой HTML, используется текстовый файл, который может легко передаваться по сети с использованием протокола HTTP. Эта особенность, а также то, что HTML является открытым стандартом и огромное количество пользователей имеет возможность применять возможности этого языка для оформления своих документов, безусловно, повлияли на рост популярности HTML и сделали его сегодня главным механизмом представления информации в Интернете.
Однако HTML сегодня уже не удовлетворяет в полной мере требованиям, предъявляемым современными разработчиками к языкам подобного рода. И ему на смену был предложен новый язык гипертекстовой разметки, мощный, гибкий и, одновременно с этим, удобный язык XML. В чем же заключаются его достоинства?
XML (Extensible Markup Language) — это язык разметки, описывающий целый класс объектов данных, называемых XML-документами. Он используется в качестве средства для описания грамматики других языков и контроля за правильностью составления документов. То есть сам по себе XML не содержит никаких тегов, предназначенных для разметки, он просто определяет порядок их создания.
Тезаурусные модели основаны на принципе организации словарей, содержат определенные языковые конструкции и принципы их взаимодействия в заданной грамматике. Эти модели эффективно используются в системах-переводчиках, особенно многоязыковых переводчиках. Принцип хранения информации в этих системах и подчиняется тезаурусным моделям.
Дескрипторные модели — самые простые из документальных моделей, они широко использовались на ранних стадиях использования документальных баз данных. В этих моделях каждому документу соответствовал дескриптор — описатель. Этот дескриптор имел жесткую структуру и описывал документ в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной БД. Например, для БД, содержащей описание патентов, дескриптор содержал название области, к которой относился патент, номер патента, дату выдачи патента и еще ряд ключевых параметров, которые заполнялись для каждого патента. Обработка информации в таких базах данных велась исключительно по дескрипторам, то есть по тем параметрам, которые характеризовали патент, а не по самому тексту патента.

8. Модели данных, описываемые в теории графов
На ранних стадиях развития баз данных и СУБД применялись две основных модели:
• иерархическая;
• сетевая;
Эти модели имели простую для понимания структуру и описываются в терминах теории графов.
Иерархическая модель данных

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

Стандарт сетевой модели данных впервые был определен в 1975 г. организацией CODASYL (Conference of Data System Languages).
Сетевая база данных - это база данных, в которой одна запись может участвовать в нескольких отношениях предок-потомок, т.е. при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом.
Следовательно, связи можно устанавливать не только между узлами соседних по подчиненности уровней, но и различных уровней:
 
Связи, присутствующие у сетевой модели и отсутствующие у иерархической, могут характеризовать вполне реальные взаимоотношения в работе торгового предприятия: представители дирекции могут курировать работу конкретных подразделений, подразделения предприятия (автохозяйство, ремонтная служба) обеспечивают работу складов, сотрудники подразделений (бухгалтеры, торговые агенты) взаимодействуют с магазинами. Таких связей можно определить очень много.
Физически данная модель также реализуется за счет хранящихся внутри самой записи указателей на другие записи, только, в отличие от иерархической модели, число этих указателей может быть произвольным.
Преимущества сетевой модели:
; универсальность (возможности сетевой модели данных являются наиболее обширными в сравнении с остальными моделями);
; возможность различного доступа к данным через значения нескольких отношений (например, через любые основные отношения).
Главный недостаток: высокая сложность (обилие понятий, вариантов их взаимосвязей, особенностей реализации и требование солидного программного обеспечения);

9. Основы реляционного моделирования

Концепция реляционной модели данных была предложена Эдгаром Коддом (сотрудник IBM) в 1970 г. в связи с необходимостью обеспечить независимость представления и описания данных от прикладных программ.
Реляционная модель позволила решить одну из важнейших задач в управлении базами данных - обеспечить независимость представления и описания данных от прикладных программ, следствием чего было бы существенное упрощение проектирования и программирования баз данных.
К основным достоинствам реляционного подхода к управлению базой данных следует отнести:
; наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными;
; наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных;
; возможность манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти.
Несмотря на все свои достоинства, реляционные системы далеко не сразу получили широкое признание. Хотя уже во второй половине 70-х годов появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД.
Рассмотрим базовые понятия реляционной модели:

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

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

Объектно-ориентированная база данных (ООБД) — база данных, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями. Результатом совмещения возможностей (особенностей) баз данных и возможностей объектно-ориентированных языков программирования являются Объектно-ориентированные системы управления базами данных (ООСУБД). ООСУБД позволяет работать с объектами баз данных также, как с объектами в программировании в ООЯП. ООСУБД расширяет языки программирования, прозрачно вводя долговременные данные, управление параллелизмом, восстановление данных, ассоциированные запросы и другие возможности.
Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Python, Java, C#, Visual Basic .NET, C++, Objective-C и Smalltalk; другие имеют свои собственные языки программирования. Объектно-ориентированные СУБД базируются на идеях, сформулированных в объектно-ориентированных языках программирования (наследования, инкапсуляции и полиморфизма).
Такого рода базы хранят методы классов, а иногда и постоянные объекты классов, что позволяет осуществлять беспрепятственную интеграцию межу данными и их обработкой в приложениях.
Таким образом, между записями базы данных и функциями их обработки вводятся определенные взаимосвязи с помощью механизмов, похожих на соответствующие средства в объектно-ориентированных языках программирования.
Объект обладает следующими характеристиками:
1. Имеет уникальный идентификатор, однозначно определяющий объект.
2. Принадлежит к некоторому классу, обладающему определенными поведением и свойствами.
3. Может обмениваться сообщениями с другими объектами.
4. Имеет некоторую внутреннюю структуру. Объекты, внутренняя структура которых скрыта от пользователей (известно только, какие функции может выполнять данный объект), называются инкапсулированными.
Поведение объекта задается с помощью методов его класса – операций, которые можно применять к объекту. Способность применять один и тот же метод для разных классов называется полиморфизмом.
В объектно-ориентированной модели возможно создание нового класса объектов на основе уже существующего класса. Этот процесс называется наследованием. Новый класс, называемый подклассом существующего класса (суперкласса), наследует все свойства и методы суперкласса. Кроме того, для него могут быть определены дополнительные свойства и методы.
Объектно-ориентированная СУБД позволяет хранить объекты и обеспечивает их совместное использование различными приложениями. Для этого она должна обладать следующими компонентами:
1. Языком баз данных, который позволяет декларировать классы объектов, а затем создавать, сохранять, извлекать и удалять объекты.
2. Хранилищем объектов, к которому могут получить доступ разные приложения. Для ссылок на объекты используются их идентификаторы.
Для практической реализации объектно-ориентированных баз данных применяются два подхода:
1. Используется язык объектно-ориентированного программирования (например, С++), дополненный средствами, позволяющими при необходимости сохранять объекты после завершения программы, с помощью которой они были созданы.
2. Основой является реляционная система, к которой добавляются объектно-ориентированные компоненты.
Основные недостатки объектно-ориентированных баз данных:
1. отсутствуют необходимое унифицированное теоретическое обоснование и стандартизованная терминология;
2. не существует формально сформулированной методологии проектирования баз данных;
3. отсутствуют средства создания нерегламентированных запросов;
4. нет общих правил поддержания согласованности данных.
В заключение можно отметить, что объектно-ориентированные базы данных в настоящее время очень сложны в проектировании и эксплуатации, что ограничивает их практическое применение. Поэтому, несмотря на продолжающиеся интенсивные исследования, объектно-ориентированная модель данных пока поддерживается лишь немногими СУБД (POET, Jasmine, Versant, Iris).
Недавно появилась еще одна - объектно-реляционная модель, в основе которой лежит реляционная модель со значительно расширенными возможностями, обеспечивающими стыковку с объектно-ориентированными языками. Объектно-реляционные базы данных появились в последнее время у значительного числа производителей СУБД (Огас1е, Informix) и сочетают в себе реляционную модель данных с концепциями объектно-ориентированного программирования (полиморфизм, инкапсуляция, наследование. Наиболее известные системы: POET фирмы POET Software, Versant фирмы Versant Technologies и др.
Достоинство объектно-ориентированной модели данных:
; возможность отображения информации о сложных взаимосвязях объектов;
; возможность идентификации отдельной записи БД и определении функции ее обработки.

11. Многомерные модели данных

В настоящее время наибольшее распространение получили три вида моделей хранилищ данных: многомерная, реляционная и комбинированная. Рассмотрим их подробнее.
В многомерной модели данные хранятся в виде гиперкубов - упорядоченных многомерных массивов.
При описании многомерной модели используют понятия Измерение и Значения:
• Измерение - множество, образующее одну из граней куба. Измерения играют роль индексов, используемых для идентификации конкретных значений данных.
• Значения - подвергаемые анализу количественные или качественные данные, которые находятся в ячейках гиперкуба.
Основные операции манипулирования измерениями:
• Сечение - подмножество, в котором фиксировано значение одного или более измерений.
• Вращение - изменение порядка измерений; обычна для двухмерных сечений (остальные фиксированные) для приведения данных к форме, удобной для восприятия;
• Свертка - замена одного из значений измерения другим - укрупненным, например, “месяц” заменяется “годом”. Свертка может быть выполнена только над измерениями, в которых имеется иерархия значений (житель дома -> все жители дома, квартала, улицы, города и т.д.).
• Детализация - операция, обратная свертке. Например, ВУЗ может быть детализирован до факультета, факультет до потока, поток до группы, и т.д.
Главным достоинством многомерной модели является быстрота поиска данных. Данные находятся на пересечении измерений гиперкуба. Для их поиска не нужно организовывать связи между таблицами, как это делается в реляционных СУБД. Благодаря этому, среднее время ответа на сложный (нерегламентированный) запрос в многомерной модели на 1 - 2 порядка выше, чем в реляционной.
Главные недостатки:
; гиперкуб требует больших объемов дисковой памяти, т.к. в нем заранее резервируется место для каждого возможного данного (этот объем резко увеличивается при высокой степени детализации данных);
; возникают сложности с модификацией данных, поскольку добавление еще одного измерения требует полной перестройки гиперкуба
Таким образом, многомерную модель ХД целесообразно использовать, когда ее объем невелик (не более 10 - 20 гигабайт), а гиперкуб имеет стабильный во времени набор измерений.

Пример. Трехмерный куб, где в качестве фактов использованы суммы продаж, а в качестве измерений - время, товар и магазин, определенных на разных уровнях группировки: товары группируются по категориям, магазины - по странам, а данные о времени совершения операций - по месяцам.
 
Системы на основе многомерных моделей данных – Essbase фирмы Arbor Softwere, Oracle Express Server фирмы Oracle и др.

12.Ключи отношения
В каждой таблице реляционной модели должен быть столбец или совокупность столбцов, значения которых однозначно идентифицируют каждую строку таблицы. Этот столбец или их совокупность и называется первичным ключом таблицы. Если таблица удовлетворяет требованию уникальности первичного ключа, она называется отношением.
В реляционной модели все таблицы должны быть преобразованы в отношения, которые связаны между собой. Связи поддерживаются внешними ключами. Внешний ключ это столбец (совокупность столбцов), значение которого однозначно характеризует значения первичного ключа другого отношения.
 
Рис.2.3. Организация ссылки от одной таблицы к другой
При установлении связи между двумя таблицами одна из них будет являться главной (master), а вторая - подчиненной (detail). Различие между ними несколько упрощенно можно пояснить следующим образом. В главной таблице всегда доступны все содержащиеся в ней записи. В подчиненной же таблице доступны только те записи, у которых значение атрибутов внешнего ключа совпадает со значением соответствующих атрибутов текущей записи главной таблицы. Причем изменение текущей записи главной таблицы приведет к изменению множества доступных записей подчиненной таблицы, а изменение текущей записи в подчиненной таблице не вызовет никаких изменений ни в одной из таблиц.
В зависимости от количества атрибутов, входящих в ключ, различают простые и сложные (или составные) ключи.
Простой ключ - ключ, содержащий только один атрибут. В общем случае операции объединения выполняются быстрее в том случае, когда в качестве ключа используется самый короткий и самый простой из возможных типов данных. С этой точки зрения наилучшим образом подходит целочисленный тип, который имеет аппаратную поддержку для выполнения над ним логических операций.
Сложный или составной ключ - ключ, состоящий из нескольких атрибутов.
В зависимости от того, содержит ли атрибут, являющийся первичным ключом, какую-либо информацию, различают искусственные и естественные ключи.
Искусственный или суррогатный ключ - ключ, созданный самой СУБД или пользователем с помощью некоторой процедуры, который сам по себе не содержит информации. Искусственный ключ используется для создания уникальных идентификаторов строк, когда сущность должна быть описана полностью, чтобы однозначно идентифицировать конкретный элемент.
Искусственный ключ часто используют вместо значимого сложного ключа, который является слишком громоздким, чтобы использоваться в реальной базе данных. Система поддерживает искусственный ключ, но он никогда не показывается пользователю.
Естественный ключ - ключ, в который включены значимые атрибуты и который, таким образом, содержит информацию. Например, в качестве первичного ключа отношения СТУДЕНТЫ можно рассматривать атрибут №_студенческого_билета. Причем данный ключ будет естественным, так как он несет вполне определенную информацию.
Каждый из типов первичных ключей имеет свои преимущества и недостатки; их обсуждению посвящено большое количество публикаций. Мы не будем проводить подробное их сравнение, а отметим лишь основные плюсы и минусы каждого из видов ключей.
Основными достоинствами естественных ключей является то, что они несут вполне определенную информацию и их использование не приводит к необходимости добавлять в таблицы атрибуты, значения которых не имеют никакого смысла и используются лишь для связи между отношениями. Иными словами, использование естественных ключей позволяет получить более компактную форму таблиц (в которых не будет избыточных, неинформативных данных) и более естественные связи между ними.
Основным же недостатком естественных ключей является то, что их использование весьма затруднительно в случае изменчивости предметной области. Следует понимать, что значения атрибутов первичного ключа не должны изменяться. То есть однажды заданное значение первичного ключа для кортежа не может быть позже изменено. Такое требование ставится в основном для поддержания целостности базы данных. Связь между отношениями обычно устанавливается именно по первичному ключу, и его изменение приведет к нарушению этих связей или к необходимости изменения записей в нескольких таблицах. Даже в сравнительно простых базах данных это может вызвать ряд трудноразрешимых проблем.
Типичным примером изменчивой предметной области, в которой для сущности невозможно определить неизменный естественный ключ, является любая область, где в качестве сущности выступает человек. Действительно, невозможно определить для человека набор атрибутов, которые были бы уникальны и неизменны на протяжении всей его жизни.
Второй, довольно существенный недостаток естественных ключей состоит в том, что, как правило, уникальные естественные ключи являются составными и содержат строковые атрибуты. Как уже отмечалось выше, максимальная скорость выполнения операций над данными обеспечивается при использовании простых целочисленных ключей. Таким образом, с точки зрения быстродействия системы естественные ключи часто оказываются неоптимальными.
Оба недостатка естественных ключей можно преодолеть, определив в отношениях суррогатные ключи, представляющие собой некоторый универсальный атрибут, как правило целочисленного типа, который не зависит ни от предметной области, ни, тем более, от структуры отношения, которое он идентифицирует. Таким образом можно обеспечить уникальность и неизменность ключа (раз он никаким образом не зависит от предметной области, то никогда не возникнет необходимость изменять его). Однако за это приходится платить избыточностью данных в таблицах.
13. Жизненный цикл БД.

Информационные системы (ИС) больших организаций содержат множество десятков баз данных, нередко распределенных между несколькими взаимосвязанными узлами вычислительной сети различных подразделений. Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем, создаваемых в различных областях экономики. Разработка крупных, многоцелевых и дорогостоящих баз данных, лежащих в основе ИС невозможна без их тщательного проектирования: слишком велико влияние этого поистине основополагающего шага на последующие этапы жизненного цикла ИС.
На ранних стадиях развития информационных систем при создании программного обеспечения большинство неудач было вызвано рядом причин:
1. отсутствием полной спецификации всех требований;
2. отсутствием приемлемой методологии разработки;
3. недостаточной степенью разделения глобального проекта на отдельные компоненты, поддающиеся эффективному контролю и управлению.
Для разрешения этих проблем был предложен структурный подход к разработке программного обеспечения, называемый жизненным циклом информационных систем или жизненным циклом разработки программного обеспечения. Жизненный цикл БД является совокупностью определенного количества этапов. Эти этапы не являются строго последовательными, а включают некоторое количество повторов предыдущих шагов в виде циклов обратной связи (рис 4.1).
 
Рис. 4.1. Жизненный цикл базы данных
1. Планирование разработки БД. Подготовительные действия, позволяющие с максимально возможной эффективностью реализовать этапы ЖЦ приложения БД. Планирование разработки БД состоит из определения трех основных компонентов: требуемого объема работы, необходимых ресурсов и общей стоимости проекта.
2. Определение требований к системе. Определение диапазона действий и границ приложения БД, состава пользователей и области применения. Важно установить границы исследуемой области и способы воздействия приложения с другими частями ИС организации. Эти границы должны охватывать не только текущих пользователей и области применения разрабатываемой системы, но и потенциальных пользователей и возможные области применения.
3. Сбор и анализ требований пользователей. Сбор и анализ информации о той части организации, работа которой будет поддерживаться с помощью создаваемой БД, а также использование информации для определения требований пользователей к создаваемой системе.
Необходимая для проектирования БД информация может быть собрана следующими способами:
; посредством опроса отдельных сотрудников предприятия, особенно специалистов в наиболее важных областях ее деятельности;
; посредством изучения документов, особенно тех, которые используются для сбора или представления информации;
; с помощью анкет, предназначенных для сбора информации у широкого круга пользователей;
; за счет использования опыта проектирования подобных систем.
Собранная информация о каждой важной области применения и пользовательской группе должна включать следующие компоненты: используемую и генерируемую документацию, подробные сведения о выполняемых транзакциях, а также список требований с указанием из приоритетов. Требование - некоторая функция, которая должна быть включена в создаваемую систему. На основании всей этой информации будут составлены спецификации требований пользователей. Объем выбранных данных зависит от сути проблемы и действующих бизнес-правил предприятия. Слишком тщательный анализ может привести к параличу сверханализа, а слишком поверхностный - к пустой трате времени и средств на проведение работ по реализации решения, которое окажется ошибочным в результате неправильной формулировки проблемы.
4. Проектирование БД - процесс создания проекта БД, предназначенной для функционирования предприятия и способствующей достижению его целей. Основными целями проектирования БД являются:
; представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей;
; создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;
; разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы.
Существует два основных подхода к проектированию систем БД: нисходящий и восходящий.
При восходящем подходе работа начинается с самого нижнего уровня - уровня определения атрибутов, которые на основе анализа существующих между ними связей группируются в отношения, представляющие типы сущностей и связи между ними. Процесс нормализации - вариант восходящего процесса, предусматривающий идентификацию требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимостях между этими атрибутами. Подходит для проектирования простых БД с относительно небольшим количеством атрибутов.
Более подходящей стратегией для проектирования сложных БД является использование нисходящего подхода. Начинается с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов.
Кроме того может использоваться смешанная стратегия при которой сначала восходящий и нисходящий подходы используются для разных частей модели, после чего все подготовленные фрагменты собираются в единое целое.
5. Выбор целевой СУБД. Выбор СУБД подходящего типа, предназначенной для поддержки приложения БД.
6. Разработка приложений. Проектирование интерфейса пользователя и прикладных программ, предназначенных для работы с БД.
7. Создание прототипа. Создание рабочей модели БД, которая обычно обладает лишь частью требуемых возможностей и не обеспечивает всей функциональности готовой системы.
8. Реализация. Физическая реализация БД и разработанных приложений.
9. Конвертирование и загрузка данных. Перенос любых существующих данных в новую БД и модификация любых существующих приложений с целью совместной работы с новой БД.
10. Тестирование. Процесс выполнения прикладных программ с целью поиска ошибок. По завершению тестирования процесс создания системы считается законченным и она может быть переедена пользователям в промышленную эксплуатацию.
11. Эксплуатация и сопровождение. Наблюдение за системой и поддержка ее нормального функционирования по окончании развертывания. Этот этап включает в себя выполнение таких действий как:
; контроль за производительностью системы. Если производительность падает ниже приемлемого уровня, то может потребоваться дополнительная настройка или реорганизация БД;
; сопровождение и модернизация приложений БД. Новые требования включаются в приложении БД при повторном выполнении предыдущих этапов ЖЦ.

14.Основные цели и задачи проектирования

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

15. Концептуальное проектирование


Основополагающим здесь является принцип, в силу которого любая прикладная область, с которой связана данная ИС, может быть формализована, т.е. описана как совокупность связанных между собой объектов, каждый из которых задается набором значений некоторых параметров (свойств) объекта.
На стадии концептуального проектирования проводится глубокий анализ предметной области, переход от неформализованного описания к ее формальному изложению с помощью специальных языковых средств.
Целью такого анализа является выяснения принципов функционирования предметной области: выявляются потоки информации, ее структура и взаимосвязи, источники и приемники; собираются формы входных и выходных документов.
В результате анализа предметной области должны быть описаны 5 компонентов инфологической модели:
• описание событий и документов, связанных с событиями;
• описание объектов, их свойств и связей между ними;
• описание потребностей пользователей (перечень запросов к БД, их частота, режим - диалоговый или пакетный);
• алгоритмические связи показателей, формулы для их расчетов;
• ограничения целостности (условия контроля данных на правильность и непротиворечивость).
На этом этапе для описания информации, циркулирующей в системе, применяют как естественный язык, так и формальные информационные модели.
Имеется целый ряд методик создания концептуальных моделей. Одна из наиболее популярных в настоящее время методик при разработке моделей использует ER-диаграммы (Entity-Relationship Diagrams). В русскоязычной литературе эти диаграммы называют "сущность - связь".
Модель ER-диаграмм была предложена Питером Пин Шен Ченом в 1976г. К настоящему времени разработано несколько ее разновидностей, но все они базируются на графических диаграммах, предложенных Ченом.
При концептуальном моделировании используются базовые понятия предметной области. Понятие "предметная область" является базисным понятием в теории баз данных (БД) и поэтому не имеет строгого определения.
В самом общем случае, предметная область (ПрО) представляет собой часть реального мира, данные о которой мы хотим отразить в базе данных.
Например, в качестве предметной области можно выбрать бухгалтерию какого-либо предприятия, отдел кадров, банк, магазин и т.д.
Предметная область бесконечна и содержит как существенно важные понятия и данные, так и малозначащие или вообще не значащие данные. Так, если в качестве предметной области выбрать учет товаров на складе, то понятия "накладная" и "счет-фактура" являются существенно важными понятиями, а то, что сотрудница, принимающая накладные, имеет двоих детей - это для учета товаров неважно. Однако, с точки зрения отдела кадров, данные о наличии детей являются существенно важными. Таким образом, важность данных зависит от выбора предметной области.
16. процесс моделирования предметной области с использованием ER-диаграмм

Основными компонентами ER - модели являются базовые понятия предметной области: сущность, свойство (атрибут) и связь.
Сущность (Entity) - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна.
При этом различают тип сущности и экземпляр сущности. Под типом сущности понимают набор однородных объектов, отображаемый как единое целое (магазин, товар и т. д.). Под экземпляром сущности подразумевается конкретный объект (магазин «Восток», товар - портфель и т. д.).
Пример: тип сущности - СТУДЕНТ, экз. сущности - Иванов А.П., Петров С.П., Сидоров К.И.;
тип сущности - ПРЕДПРИЯТИЕ, экз. сущности - завод БМЗ, банк “Газпромбанк” и др.
В диаграммах ER-модели сущность представляется в виде прямоугольника, в котором указывается его имя (как правило существительное).
ПРЕДПРИЯТИЕ
Считается, что каждый тип сущности полностью описывается совокупностью его свойств. Таким образом, каждая сущность должно иметь следующие характеристики: имя, объем (количество сущностей, которые можно описать данным понятием), содержание (совокупность свойств).
Свойство (атрибут) - это элементарная единица структуры сущности, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения ее состояния.
Пример: свойства понятия СТУДЕНТ - фамилия, имя, № зачетки, адрес, возраст, пол и т.п.
Набор свойств понятия в принципе бесконечен, но при разработке ЭИС он зависит от информационных потребностей пользователя и решаемых им задач. При составлении инфологической модели следует как можно более полно описать свойства понятий, учитывая не только текущие задачи, но и возможные будущие потребности пользователей ЭИС.

Свойства сущностей делятся на три типа :
; Ключевые свойства позволяют различить сущности внутри одного понятия (ключ может состоять из нескольких свойств).
; Дифференциальные свойства содержат смысл понятия (то, что отличает его от других понятий),
; Валентные свойства служат для связи между разными понятиями.
Пример:  Код_студента -  ключевое свойство (оно уникально для каждого студента);
Фамилия, Имя, Адрес и др - дифференциальные свойства (они отличают это понятие, например, от понятия ПРЕДПРИЯТИЕ;
Номер группы  - валентное свойство, так как оно может применяться для связи с другими сущностями (ГРУППА, СПЕЦИАЛЬНОСТЬ и т.п.).
Для краткого описания сущности используется ее схема, которая представляет собой совокупность свойств сущности: P ( S1, S2, ... Sn).
Ключевое свойство в схеме сущности выделяют подчеркиванием.
Пример: СТУДЕНТ (Код_студента, ФИО, Адрес, Группа);
ГРУППА(КодГруппы, Название, Кол-воСтудентов, КодСпециальности).
На ER- диаграммах свойства сущностей можно отображать двумя способами. Например, на рис. 4.2 а) имена свойств записаны малыми буквами внутри прямоугольника под именем сущности. На рис. 4.2 б) свойства вынесены за прямоугольник и заключены в овал.
 
      а)                б)   
Рис. 4.2. Варианты изображения свойств понятия
Связь - это ассоциация между двумя сущностями. Она всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и им же самим (рекурсивная связь). В любой связи выделяются два конца, на каждом из которых указывается степень конца связи (сколько сущностей данного понятия связывается) и обязательность связи (т.е. любая ли сущность данного понятия должна участвовать в данной связи).
На диаграмме связь изображается РОМБОМ, соединяющим связываемые сущности, внутри которого указывается вид связи (обычно выражается глаголом).
Пример, сущности Директор и Сотрудник могут быть соединены связью Руководит. Между двумя сущностями может быть установлено несколько связей: Продавец – Продает – Товар, Продавец – Фасует – Товар, Продавец – Учитывает – Товар.
 
Важнейшими характеристиками связей между сущностями, а также между сущностями и их свойствами являются следующие:
; время существования - различают постоянные, долговременные и кратковременные связи.
Например, значение свойства РАЗМЕР_СТИПЕНДИИ для понятия СТУДЕНТ обновляется раз в семестр, а свойство НОМЕР_ЗАЧЕТКИ постоянно на протяжении обучения. Время существования влияет на то, как отображается свойство или связь в базе данных: будет ли она заложена в структуру БД, либо будет реализована алгоритмическим путем (в программе). Кратковременные, легко вычисляемые свойства и связи рекомендуется реализовывать алгоритмически.
; избирательность (кардинальность, класс принадлежности) - различают необязательные и обязательные, возможные и условные связи.
Класс принадлежности связи для некоторой сущности является обязательным, если в данной связи должен участвовать каждый экземпляр сущности (все продавцы продают товары), и необязательным, если некоторые экземпляры сущности не участвуют в связи (не все товары доставлены железнодорожным транспортом). При этом связь может быть обязательной с одной стороны и необязательной с другой стороны.
; ассоциативность (степень, мощность) - различают связи 1 : 1, 1 : М, N : M.
Связь 1 : 1 - это такая, при которой каждой сущности понятия А соответствует только одна сущность понятия В, например: СТУДЕНТ ;  АДРЕСНЫЕ ДАННЫЕ.
Связь 1 : М - это такая, при которой каждой сущности понятия А соответствует несколько (или 0) сущностей понятия В, например: ГРУППА ; СТУДЕНТ.
Связь N : M - это такая, при которой каждой сущности понятия А соответствует несколько (или 0)  сущностей понятия В и наоборот, например: СТУДЕНТ ; ПРЕПОДАВАТЕЛЬ.

17. Даталогическое проектирование

Концептуальная модель данных является источником информации для фазы логического проектирования БД.
Основным этапом данного проектирования является выбор конкретной СУБД. При этом не рассматриваются особенности физической организации ее структур хранения данных.
Можно выделить следующие этапы выбора СУБД:
1. Выявление внешних ограничений, к которым относят требования пользователя к решению задач, тип технических средств, ОС, сроки разработки, трудовые и финансовые ресурсы и т.п.
2. Выделение СУБД - претендентов, подходящих по внешним ограничениям.
3. Моделирование БД (преобразование инфологической модели в даталогическую для каждой из СУБД - претендентов и оценка затрат на программирование и поддержку БД).
4. Сравнительный анализ полученных вариантов.
Для окончательного выбора рекомендуется количественно оценить каждую характеристику выбранных СУБД:
• общие технические характеристики (количество записей в файле, полей в записи, файлов в одной БД, способ реализации связей и т.п.),
• соответствие структуры данных и методов доступа классу решаемых задач;
• средства поддержки целостности БД,
• языковые средства и их поддержка,
• трудоемкость разработки прикладных программ,
• стоимость эксплуатации системы.
С помощью метода экспертных оценок отбирают 2-3 подходящих СУБД. Окончательное решение принимают с помощью экспериментального моделирования БД: создаются тестовые базы данных для каждой из СУБД и решаются типовые задачи, затем оценивают эффективность каждой СУБД. Выбор СУБД может потребовать очень больших затрат труда специалистов, но они оправданы, так как СУБД оказывает решающее влияние на все параметры информационной системы.
Рассмотрим детальнее внешние требования, которые современное быстро развивающееся предприятие предъявляет к информационной системе.
Во-первых, организация будет расти, и к информационной системе будут подключаться все новые и новые сотрудники, следовательно, система должна быть многопользовательской.
Во-вторых, по мере расширения организация приобретает новые, не обязательно однотипные компьютеры. Значит, СУБД должна функционировать на множестве моделей компьютеров различных производителей, причем прикладные программы, разработанные для одной платформы, должны быть без особого труда переносимы  на другую.
В-третьих, база данных организации будет непрерывно расти и расширяться. Следовательно, СУБД должна обеспечивать обработку и хранение больших объемов данных и поддерживать быстрорастущие БД.
В-четвертых, в процессе развития информационной системы для реализации новых функций могут потребоваться различные механизмы обработки данных. Некоторые из них не обязательно потребуются сегодня, но непременно будут востребованы завтра и станут жизненно необходимыми послезавтра. Следовательно, СУБД должна быть многофункциональной.
В-пятых, для расширения информационной системы могут потребоваться новые компьютеры и новые программные системы, поэтому СУБД должна поддерживать как общепринятые стандарты сетевого обмена (TCP/IP, DECnet, IPX/SPX, NetBIOS, SNA), так и стандарты межпрограммных интерфейсов (ATMI, XA, ODBC).
И, наконец, возможно, что в организации появятся филиалы, которые будут работать с локальными БД. Значит, возникнет потребность объединения локальных БД в распределенную базу данных. Следовательно, СУБД должна управлять распределенными базами данных.
Рассмотрим процесс датологического проектирования в целом (рис 4.4).
 
Рис. 4.4. Технологическая схема даталогического проектирования БД
Исходными данными для даталогического проектирования БД является инфологическая модель, сведения о типе модели данных выбранной СУБД (реляционная, сетевая, иерархическая или другая) и информация о средствах и методах автоматизации разработки БД.
Результатом даталогического проектирования является описание логической структуры БД на языке описания данных (ЯОД), которое для наглядности часто сопровождается графическим изображением структуры БД.
Важной проблемой на этом этапе является выбор правильного соотношения декларативного и процедурного описания базы данных.
Декларативными средствами описывают объекты, их свойства и связи, которые будут постоянно храниться в виде структур базы данных.
Процедурными средствами (на языках программирования и запросов к БД) можно описать вычисляемые показатели, методы контроля данных, то есть те объекты, свойства и связи, которые не хранятся в БД постоянно, а получаются в результате вычислений по мере необходимости.
Как правило, для нестабильных и сложно вычисляемых свойств и связей в БД отводят специальные поля для хранения результатов расчета, а легко вычисляемые показатели (сумма, среднее значение и т.п.) получают динамически с помощью запроса к БД

18. Физическое моделирование

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

19. Программные средства автоматизированного проектирования ИС и их БД.

Средства автоматизации разработки баз данных и приложений делятся на CASE и RAD - системы.
CASE-системы (Computer Aided Software Engineering) - программные средства, поддерживающие процессы автоматизированного проектирования баз данных, создания и сопровождения ПО и баз данных, генерацию кода, тестирование, документирование и управление проектом).
RAD - средства предназначены для быстрой разработки приложений.
Данные средства бывают как автономными (например, пакеты ERWIN, BPWIN, CLARION), так и встроенными в мощные СУБД (S-designor, Power Designor и др.).
Указанные средства поддерживают ранние этапы разработки ИС (построение концептуальной модели системы), автоматически генерируют структуру БД в соответствии с концептуальной моделью, позволяют быстро создать действующий макет приложения (экранные формы, отчеты, меню) для согласования с пользователем.
Полный комплект CASE- средств включает в себя:
; репозиторий (словарь данных) для хранения версий проекта, синхронизации работы группы разработчиков, контроля метаданных;
; графические средства проектирования и анализа (Design/IDEF, BPWIN, CASE-аналитик);
; генераторы кодов, языки 4GL и другие средства программирования (Power Builder, Delphi);
; средства разработки БД (ERWIN, Designer 2000),
; средства документирования проектов;
; средства тестирования программ и схем БД;
; средства управления проектом,
; средства реинжиниринга.
Следует отметить, что на CASE-систему нельзя уповать, как на волшебную палочку: это лишь средство автоматизации, упрощающее и облегчающее работу системного аналитика, архитектора, дизайнера и разработчика, но никак не могущее выполнить за них аналитическую работу. Современные CASE-технологии требуют высочайшей квалификации в области системного анализа и теории проектирования баз данных.

20. Язык определения данных DDL

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

21. Язык управления данными DML

Язык DML - язык, содержащий набор операторов для поддержки основных операций манипулирования содержащимися в базе данными.
К операциям управления данными относятся:
; вставка в базу данных новых сведений;
; модификация сведений, хранимых в базе данных;
; извлечение сведений, содержащихся в базе данных;
; удаление сведений из базы данных.
Таким образом, одна из основных функций СУБД заключается в поддержке языка манипулирования данными, с помощью которого пользователь может создавать выражения для выполнения перечисленных выше операций с данными.
Языки DML отличаются базовыми конструкциями извлечения данных. Следует различать два типа языков DML: процедурный и непроцедурный. Основное отличие между ними заключается в том, что процедурные языки указывают то, как можно получить результат оператора языка DML, тогда как непроцедурные языки описывают то, какой результат будет получен. Как правило, в процедурных языках записи рассматриваются по отдельности, тогда как непроцедурные языки оперируют с целыми наборами записей.
Процедурный язык DML - язык, который позволяет сообщить системе о том, какие данные необходимы, и точно указать, как их можно извлечь.
С помощью процедурного языка DML пользователь, а точнее - программист, указывает на то, какие данные ему необходимы и как их можно получить. Это значит, что пользователь должен определить все операции доступа к данным (осуществляемые посредством вызова соответствующих процедур), которые должны быть выполнены для получения требуемой информации. Обычно такой процедурный язык DML позволяет извлечь запись, обработать ее и, в зависимости от полученных результатов, извлечь другую запись, которая должна быть подвергнута аналогичной обработке, и т.д. Подобный процесс извлечения данных продолжается до тех пор, пока не будут извлечены все запрашиваемые данные. Языки DML сетевых и иерархических СУБД обычно являются процедурными.
Непроцедурный язык DML - язык, который позволяет указать лишь то, какие данные требуются, но не то, как их следует извлекать.
Непроцедурные языки DML позволяют определить весь набор требуемых данных с помощью одного оператора извлечения или обновления. С помощью непроцедурных языков DML пользователь указывает, какие данные ему нужны, без определения способа их получения. СУБД транслирует выражение на языке DML в процедуру (или набор процедур), которая обеспечивает манипулирование затребованным набором записей. Данный подход освобождает пользователя от необходимости знать детали внутренней реализации структур данных и особенности алгоритмов, используемых для извлечения и возможного преобразования данных. В результате работа пользователя получает определенную степень независимости от данных.
Непроцедурные языки часто также называют декларативными языками. Реляционные СУБД в той или иной форме обычно включают поддержку непроцедурных языков манипулирования данными - чаще всего это бывает язык структурированных запросов SQL (Structured Query Language) или язык запросов по образцу QBE (Query-by Example). Непроцедурные языки обычно проще понять и использовать, чем процедурные языки DML, поскольку пользователем выполняется меньшая часть работы, а СУБД – большая

22. Табличный язык запроса QBE

Табличные языки  запросов широко используются в современных СУБД, один из них - Query by Example (QBE, "запрос по образцу") - предназначен для конечного пользователя и позволяет описывать запросы манипулирования данными. Достоинство языка QBE -  простота изучения, понимания и применения.
Первые сведения о языке QBE появились в 1975 году, с тех пор многие его идеи были развиты и с появлением оконных оболочек стали использоваться повсеместно. Практически во всех современных СУБД имеется та или иная реализация языка QBE. Существуют и универсальные программы, обеспечивающие манипулирование данными в форматах различных СУБД, например,  Microsoft QUERY (входит в  MS Office), Borland BDE ( включен в пакет Delphi) и др. 
В основу языка положены две фундаментальные концепции:
- программирование запросов представляет собой заполнение двумерных таблиц - шаблонов;
- таблица - шаблон представляет собой пример решения задачи, как оно видится пользователю.
В шаблоне запроса в качестве заголовков столбцов применяют имена полей из базы данных,  в строках таблицы задаются критерии поиска,  выборки, сортировки или формулы вычисления, определяется видимость полей и т.п. Связь исходных таблиц между собой по общим полям также описывается в шаблоне запроса.
Результат выполнения запроса также выглядит в виде таблицы, которую можно сохранить,  переименовать  и далее  работать как с обычной таблицей БД. Сам шаблон запроса также может быть сохранен для повторного применения.
К запросам манипулирования данными относят отбор, добавление, удаление, изменение данных в БД. Рассмотрим реализацию этих операций в языке QBE.

23. Элементы языка SQL

SQL -оператор состоит из зарезервированных слов, а также из слов, определяемых пользователем. Зарезервированные слова являются постоянной частью языка SQL и имеют фиксированное значение. Их следует записывать в точности так, как это установлено, и нельзя разбивать на части для переноса из одной строки в другую. Слова, определяемые пользователем, задаются самим пользователем (в соответствии с определенными синтаксическими правилами) и представляют собой имена различных объектов базы данных - таблиц, столбцов, представлений, индексов и т.д. Слова в операторе размещаются в соответствии с установленными синтаксическими правилами. Хотя в стандарте это не указано, многие диалекты языка SQL требуют задания в конце оператора некоторого символа, обозначающего окончание его текста (как правило, с этой целью используется символ точки с запятой <;>).
Большинство компонентов SQL -операторов не чувствительно к регистру. Это означает, что могут использоваться любые буквы - как строчные, так и прописные. Одним важным исключением из этого правила являются символьные литералы-данные, которые должны вводиться точно так нее, как были введены соответствующие им значения, хранящиеся в базе данных. Например, если в базе данных хранится значение фамилии "SMITH", а в условии поиска указан символьный литерал "Smiht", то эта запись не будет найдена.
Поскольку язык SQL имеет свободный формат, отдельные SQL -операторы и их последовательности будут иметь более читабельный вид при использовании отступов и выравнивания. Рекомендуется придерживаться следующих правил.
; Каждая фраза в операторе должна начинаться с новой строки.
; Начало каждой фразы должно быть выровнено с началом остальных фразоператора.
; Если фраза имеет несколько частей, каждая из них должна начинаться с новой строки с некоторым отступом относительно начала фразы, что будет указывать на их подчиненность.

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

25. Основные приемы нормализации данных


Зачастую нормализация осуществляется в несколько последовательно выполняющихся этапов, каждый из которых соответствует некоторой нормальной форме, обладающей известными свойствами. В ходе нормализации формат отношений становится все более строгим и менее уязвимым по отношению к аномалиям обновления. При работе с реляционной моделью данных важно понимать, что только удовлетворение требований первой нормальной формы (1НФ) обязательно для создания отношений. Однако, для того чтобы избежать аномалий обновления нормализацию рекомендуется выполнять как минимум до ЗНФ.
Основная цель проектирования реляционной базы данных заключается в группировании атрибутов в отношения так, чтобы минимизировать избыточность данных и таким образом сократить объем памяти, необходимый для физического хранения отношений, представленных в виде таблиц. При работе с отношениями, содержащими избыточные данные, могут возникать проблемы, которые называются аномалиями обновления и подразделяются на аномалии вставки, удаления и модификации.
Функциональная зависимость (functional dependency) описывает связь между атрибутами и является одним из основных понятий нормализации.
Например, если в отношении R, содержащем атрибуты А и В, атрибут В функционально зависит от атрибута А (что обозначается как А->В), то каждое значение атрибута А связано только с одним значением атрибута В. Причем каждый из атрибутов А и В может состоять из одного или нескольких атрибутов.
Рассмотрим основные нормальные формы реляционных баз данных.

Первая нормальная форма (1НФ)

Перед обсуждением первой нормальной формы целесообразно предварительно дать определение того состояния, которое предшествует ей.
Ненормализованная форма (ННФ) - таблица, содержащая одну или несколько повторяющихся групп данных.
Первая нормальная форма (1НФ) - отношение, в котором на пересечении каждой строки и каждого столбца содержится только одно значение.
Процесс нормализации начинается с преобразования данных из формата источника (например, из формата стандартной формы ввода данных) в формат таблицы со строками и столбцами. На исходном этапе таблица находится в ненормализованной форме (ННФ) и часто называется ненормализованной таблицей. Для преобразования ненормализованной таблицы в первую нормальную форму (1НФ) в исходной таблице следует найти и устранить все повторяющиеся группы данных. Повторяющейся группой называется группа, состоящая из одного и более атрибутов таблицы, в которой возможно наличие нескольких значений для единственного значения ключевого атрибута таблицы. Обратите внимание на то, что в данном контексте термин "ключ" равным образом относится и к одному атрибуту, и к группе атрибутов, которые единственным образом идентифицируют каждую строку ненормализованной таблицы. Существует два подхода исключения повторяющихся групп из ненормализованных таблиц.
В первом подходе повторяющиеся группы устраняются путем ввода соответствующих данных в пустые столбцы строк с повторяющимися данными. Иначе говоря, пустые места при этом заполняются дубликатами неповторяющихся данных. Этот подход часто называют "выравниванием" ("flattening") таблицы. Полученная в результате этих действий таблица, которая теперь будет называться отношением, содержит атомарные (или единственные) значения на пересечении каждой строки с каждым столбцом, а потому находится в первой нормальной форме. В результате такого подхода в полученное отношение вносится некоторая избыточность данных, которая в ходе дальнейшей нормализации будет устранена.
Во втором подходе один атрибут или группа атрибутов назначаются ключом ненормализованной таблицы, а затем повторяющиеся группы изымаются и помещаются в отдельные отношения вместе с копиями ключа исходной таблицы. Далее в новых отношениях устанавливаются первичные ключи. Иногда ненормализованные отношения могут содержать одну или несколько повторяющихся групп внутри повторяющихся групп первого порядка. В таких случаях данный прием применяется до тех пор, пока повторяющихся групп совсем не останется. Полученный набор отношений будет находиться в первой нормальной форме только тогда, когда ни в одном из них не будет повторяющихся групп атрибутов.
Хотя оба этих подхода одинаково корректны, следует отметить, что при использовании второго подхода полученные отношения находятся как минимум в 1НФ и обладают меньшей избыточностью данных. При выборе первого подхода выровненное 1НФ-отношение декомпозируется в ходе дальнейшей нормализации на те же отношения, которые могли бы быть получены с помощью второго подхода.

Вторая нормальная форма (2НФ)

Вторая нормальная форма (2НФ) основана на понятии полной функциональной зависимости, которая описывается ниже.
В случае полной функциональной зависимости атрибут В называется полностью функционально зависимым от атрибута А, если атрибут В функционально зависит от полного значения атрибута А и не зависит ни от какого подмножества полного значения атрибута А.
Функциональная зависимость А>В является полной функциональной зависимостью, если удаление какого-либо атрибута из А приводит к утрате этой зависимости. Частичной функциональной зависимостью называется такая зависимость А->В, если в А есть некий атрибут, при удалении которого эта зависимость сохраняется.
Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или больше атрибутов. Дело в том, что отношение с первичным ключом на основе единственного атрибута всегда находится, по крайней мере, в 2НФ.
Вторая нормальная форма (2НФ) – отношение, которое находится в первой нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, характеризуется полной функциональной зависимостью от этого первичного ключа.

Третья нормальная форма (ЗНФ)

Хотя 2НФ-отношения в меньшей степени обладают избыточностью данных, чем 1НФ-отношения, они все еще могут страдать от аномалий обновления.
Если для атрибутов А, В и С некоторого отношения существуют зависимости вида А->В и В->С, то говорят, что атрибут С транзитивно зависит от атрибута А через атрибут В (при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С).
Транзитивная зависимость является описанием такого типа функциональной зависимости, которая возникает при наличии следующих функциональных зависимостей между атрибутами А, В и С:  А->В и В->С.
В данном случае транзитивная зависимость А->С осуществляется через атрибут В. Это утверждение справедливо только в том случае, если атрибут А функционально не зависит от атрибутов В и С.
Третья нормальная форма (ЗНФ) - отношение, которое находится в первой и второй нормальных формах и не имеет не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа.
Нормализация 2НФ-отношений с образованием ЗНФ-отношений включает устранение транзитивных зависимостей. Если в отношении существует транзитивная зависимость между атрибутами, в таком случае транзитивно-зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта.
Подготовленные, таким образом, структуры данных можно использовать для реализации в конкретных реляционных СУБД.

26. Сходства и различия запросов и фильтров

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

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

 Запросы могут использоваться только с закрытой таблицей или запросом. Фильтры обычно применяются при работе в режиме Формы или в режиме Таблицы для просмотра или изменения подмножества записей. Запрос можно использовать:
 для просмотра подмножества записей таблицы без предварительного открытия этой таблицы или формы;
 для того чтобы объединить в виде одной таблицы на экране данные из нескольких таблиц;
 для просмотра отдельных полей таблицы;
 для выполнения вычислений над значениями полей.
27. Технология работы с таблицами и запросами в среде СУБД Access.

Основу базы данных составляют таблицы - именно в них хранятся все данные. Структура таблиц должна быть тщательно спланирована. При планировании таблиц необходимо избегать дублирования информации в разных таблицах.
Каждая таблица описывает некоторый класс объектов выбранной предметной области, например, сотрудников предприятия, а каждая строка - запись - содержит информацию о конкретном объекте (сотруднике). Каждый же столбец - поле описывает один из атрибутов данного объекта. Столбец содержит однотипную информацию.
Длина имени таблицы ; не более 64 символов.
Длина имени поля ; не более 64 символов.
Количество полей  в одной таблице ; не более 255
Количество записей ; неограниченно
Суммарный объем информации во всей БД ; не более 1 гигабайта
Целесообразно имена полей выбирать не длиннее хранимых данных, но отображающих их смысл. В именах можно использовать любые комбинации букв, цифр, пробелов и других символов, за исключением «.», «!», «'», «[» и «]».
Для каждого поля необходимо указать тип данных. Тип данных определяет вид и диапазон допустимых значений, которые могут быть введены в поле, а также объем памяти, выделяющийся для этого поля.
Таблица может содержать следующие типы полей:
; Текстовый - короткий текст. Текст и числа, например, имена и адреса, номера телефонов и почтовые индексы. Текстовое поле может содержать до 255 символов.
; Поле Memo - длинный текст и числа, например, комментарии и пояснения. Memo-поле может содержать до 65 536 символов.
; Числовой - общий тип для числовых данных, допускающих проведение математических расчетов, за исключением расчетов для денежных значений. Свойство Размер поля позволяет указать различные типы числовых данных. Длина – 8 байт. Точность – 15 знаков.
; Дата/время - значения даты и времени. Пользователь имеет возможность выбрать один из многочисленных стандартных форматов или создать специальный формат. Длина - 8 байт.
; Денежный - денежные значения. Числа представляются с двумя знаками после запятой. Не рекомендуется использовать для проведения денежных расчетов значения, принадлежащие к числовому типу данных, так как последние могут округляться при расчетах. Значения типа "Денежный" всегда выводятся с указанным числом десятичных знаков после запятой.
; Счетчик - автоматически вставляющиеся последовательные номера. Счетчик увеличивается на единицу для каждой следующей записи. Нумерация начинается с 1. Поле счетчика удобно для создания ключа. В таблице может быть только одно такое поле. Длина - 4 байта.
; Логический - значения "Да"/"Нет", "Истина"/"Ложь", "Вкл"/"Выкл", т.е. одно из двух возможных значений. Длина - 1 байт.
; Поле объекта OLE - объекты, созданные в других программах, поддерживаю¬щих протокол OLE, например графики, рисунки и т.п. Объекты связываются или внедряются в базу данных MS Access через элемент управления в форме или отчете. Максимальный объем информации объекта OLE -1 Гбайт.
; Гиперссылка - поле, в котором сохраняются адреса гиперссылок, позволяющих переходить к файлам, фрагментам файлов или веб-страницам. Гиперссылка может иметь вид пути UNC либо адреса URL. Сохраняет до 64 000 знаков.
Для создания отношений необходимо указать поля в двух таблицах, которые содержат одни и те же данные. Обычно такое поле в одной из таблиц (главной) является ключевым. Имена связывающих полей могут отличаться, но типы и свойства должны совпадать. Возможна связь между полем типа Счетчик и полем типа Число с форматом Длинное целое.
Запрос - это средство Access для выборки данных из базы данных в форме таблицы, заполняемой по заданному условию, а также для выполнения определенных действий над табличными данными.
Условие может определять:
; - порядок сортировки выводимых данных;
; - фильтрацию данных;
; - вычисляемые поля;
; - вывод данных из нескольких связанных таблиц;
Запросы по существу являются псевдотаблицами и их можно использовать также как и таблицы. Применение запросов позволяет избежать дублирования данных в таблицах и обеспечивает максимальную гибкость при поиске и отображении данных БД. С помощью запроса создается временная таблица - динамический набор данных. С помощью запроса можно осуществить выборку данных сразу из нескольких таблиц. В Access для создания запросов можно использовать до 32 таблиц. В одном запросе можно проводить сортировку по 10 полям.
Очевидно, что запросы перекрывают возможности фильтрации, т.е. являются более мощным инструментом обработки данных в БД.
В СУБД MS Access используется методология «Запрос по образцу» (Query by Example или QBE), включающая форму (бланк) запроса и специальный язык для её заполнения. Переход к формированию запроса реализуется путем выбора вкладки Запросы конкретной БД и нажатия кнопки Создать, после чего СУБД предлагает различные варианты реализации запросов.
Все запросы можно разделить на две группы:
• запросы-выборки;
• запросы-действия.
Запросы-выборки извлекают данные из таблиц в соответствии с заданными условиями. Самое главное в таких запросах - возможность использования критериев выборки, которые вводятся в строку Условие отбора. Можно выделить следующие типы запросов на основе критериев выборки:
1. Выборка по строгому совпадению. В строку Условие отбора для определенного поля вводится одно из значений, существующих в таблице.
Данные запросы можно параметризовать, т.е. вводить условия отбора в виде параметра при каждом запуске запроса, что устраняет необходимость предварительно его модификации. Для параметризации необходимо в строке Условие отбора вместо самого условия ввести текст приглашения на его ввод по формату: [текст приглашения].
2. Выборка по строгому несовпадению. В этом случае в выборку отбираются все записи таблицы, кроме записей, содержащих значение, указанное в строке Условие отбора. Для реализации запроса перед значением вводится префикс Not.
3. Выборка по неточному совпадению. Для выборки записей в условиях неполноты знаний о требуемых значениях используется оператор Like <условие>. Само <условие> образуется следующими подстановочными символами:
? - любой один символ; * - любое количество символов; # - любая одна цифра;
[список_символов] - любой символ из списка;
[!список_символов] - любой символ, не входящий в список;
В списке можно указывать сразу диапазон символов. Например, [A-К]
4. Выборка по диапазону. Для формирования данных условий выбора используются операторы сравнения >, >=, <, <= и <>. Операции сравнения могут связываться логическими операциями And (И) и Or (ИЛИ). Например, выбор книг стоимостью от 100 до 200 рублей может быть реализован через ввод в запросе условия в поле Стоимость в виде >=100 and <=200.
________________________________________
Примечание. В выражениях отбора можно использовать знаки математических операций +, -, /, * и неограниченное число круглых скобок. Сложные выражения в условиях отбора могут формироваться с помощью соответствующего построителя, который вызывается кнопкой Построить на панели инструментов.
________________________________________
5. Запрос с вычислениями. Такой запрос позволяет получить дополнительную информацию в процессе выборки, например, стоимость всей партии товара при хранимой в таблице информации о количестве товара и стоимости единицы его продукции. Для этого в строку Поле пустого столбца заносят выражение для вычисления по следующему формату: <Название формируемого поля> : <выражение>.
В <выражении> можно использовать знаки арифметических операций, круглые скобки и имена полей в квадратных скобках. Например, стоимость партии можно вычислить по выражению Стоимость партии: [количество товара]*[стоимость единицы товара].
6. Запрос с групповыми операциями. СУБД Access позволяет находить интегральные показатели для групп записей в таблице. Каждая такая группа характеризуется одинаковым значением по какому-то полю, например, одинаковым названием отдела. Для перехода в данный режим запросов необходимо в панели инструментов нажать клавишу Групповые операции, что приведет к появлению в бланке запроса новой строки с одноименным названием. В ячейках данной строки указывается или режим группировки по некоторому полю (опция Группировка), или название групповой операции.
При запуске запроса СУБД разбивает таблицу на группы, число которых равно числу существующих значений в группируемом поле, и реализует для каждой группы требуемую операцию, т.е. число строк в выборке равно числу групп.
В строке Группировка можно указать только одну итоговую функцию. Если нужно провести несколько итоговых операций (min, max, среднее значение), то одно и тоже поле включается в бланк несколько раз.
Кроме того, в ячейках строки Групповые операции можно выбрать еще два режима: Выражение и Условие. Режим Выражение позволяет формировать вычисляемое поле, содержащее статистические функции, в заголовке столбца бланка Поле. Режим Условие определяет ограничение записей (задается в строке Условия отбора) перед их группировкой и проведением расчетов.
Запросы-действия предназначены для выполнения требуемых действий над данными таблиц. Они позволяют добавлять, изменять или удалять данные. В Access существует следующие виды запросов-действия:
1. Запрос-создание новой таблицы предназначен для сохранения результатов запроса в виде новой таблицы.
Исходно формируется обычный запрос на выборку необходимой информации из таблицы. После проверки результатов его выполнения производится возврат в режим конструктора запросов и нажимается кнопка Тип запроса на панели инструментов или выбирается команда меню Запрос. В появившемся списке выбирается опция Создание таблицы, после чего СУБД запрашивает её имя. Указывается имя создаваемой таблицы и нажимается кнопка ОК.
2. Запрос-добавление выборки в другую таблицу. Выборку можно добавить к другой таблице, однотипной по структуре или с изменением структуры выборки.
Для этого необходимо сформировать обычный запрос. Далее в режиме конструктора запроса нажимается кнопка Тип запроса на панели и в появившемся списке выбирается опция Добавление, после чего СУБД запрашивает имя таблицы, к которой будет добавлена выборка.
Если структура выборки и целевой таблицы не совпадают, то в целевую таблицу добавляются значения только тех полей выборки, имена которых совпадают с именами полей целевой таблицы.
3. Запрос-удаление. С помощью запросов можно удалить записи из таблицы.
Для этого необходимо сформировать обычный запрос и оценить результаты его выполнения. Далее в режиме конструктора нажимается кнопка Тип запроса на панели инструментов и в появившемся списке выбирается опция Удаление, после чего в бланке запроса появляется новая строка с именем Удаление, куда можно вводить дополнительные условия на выборку удаляемых записей.
4. Запрос-обновление. С помощью запросов можно обновлять в единой операции некоторые или все значения выбранных полей.
Для этого формируется обычный запрос и в режиме конструктора нажимается кнопка Тип запроса на панели инструментов и выбирается опция Обновление, после чего в бланке запроса появляется новая строка с именем Обновление. В ней задаются новые значения полей таблицы, в том числе и вычисляемые выражения. Далее запрос запускается на выполнение и СУБД указывает число модифицируемых записей и просит подтвердить изменения кнопкой ОК.

28. Технология работы с формами и отчетами


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

2.2.4. Технология работы с отчетами

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

29. Простейшая концепция защиты данных

Она называется работой на высшем уровне секретности и состоит в двух правилах:
; необходимо проверять полномочия пользователя или программы, то есть их право  производить определенные действия над объектами БД;
; необходимо проверять подлинность пользователя или программы, то есть достоверно подтверждать, что пользователь именно тот, за кого он себя выдает.
Схема доступа к данным во современных СУБД выглядит примерно одинаково и базируется на трех принципах: 
1) Идентификация пользователя - пользователям (их группам) назначается уникальный номер и пароль. В ряде СУБД (Oracle, Sybase) используется собственная система паролей, в других (Ingres, Informix) - пароль и идентификатор из операционной системы.
2) Управление доступом - конкретный пользователь обладает конкретными правами доступа к конкретному объекту (объекты доступа - это элементы базы данных, доступом к которым можно управлять, например, таблицы и их части, представления, формы, отчеты, прикладные программы и т.д.). СУБД проверяет, не нарушено ли какое-либо ограничение, в случае нарушения выдает пользователю сообщение об ошибке и фиксирует факт нарушения в специальном журнале.
3) Привилегии - это операции, которые разрешено выполнять пользователю над конкретными объектами. Например, может быть разрешено выполнение над определенной таблицей операций ВЫБРАТЬ и ДОБАВИТЬ.
Для проверки полномочий СУБД поддерживает матрицу «пользователи / объекты БД», в каждой ячейке которой содержится список разрешенных для пользователя Х операций над объектом У. Проверка подлинности обычно обеспечивается средствами защиты вычислительных сетей и операционных систем. 
Установлением и контролем прав доступа пользователей к БД  занимается администратор базы данных, функции которого при решении вопросов  защиты данных состоят в следующем:
; классификация данных с точки зрения степени защиты,
; определение прав доступа пользователей к данным,
; организация системы контроля за доступом к данным,
; периодическая проверка системы защиты,
; исследование случаев нарушения защиты и их предотвращение,
; внедрение и проверка новых средств защиты.
Группировка пользователей. Когда каждому физическому лицу присваивается уникальный идентификатор и собственные привилегии, то при увеличении количества пользователей администратору становится все труднее управлять защитой БД, поэтому в современных БД пользователей объединяют в группы. Применяются следующие способы определения групп пользователей:
1) Группе лиц (например, студентов одной группы) дается один и тот же пароль для доступа к БД. Это упрощает работу администратора БД, однако такой способ в основном предполагает разрешение на просмотр и добавление данных, но ни в коем случае - на удаление и обновление.
2) Каждый пользователь, кроме собственного идентификатора, имеет также идентификатор группы, к которой он принадлежит (структурное подразделение организации, выполняемая роль по отношению к БД). Привилегии можно устанавливать не только для отдельных пользователей, но и целиком для группы.
3) Прикладной программе, работающей с БД, назначаются свои привилегии, которые могут быть шире, чем у пользователя, который ее применяет (пароль и привилегии прикладной программы называют ролью).

30. Многоуровневая защита данных.

Простейшая концепция защиты оказывается неудовлетворительной, если в учреждении необходимо организовать многоуровневую среду защиты информации, при которой информация различается по степени секретности, а пользователи имеют разную степень «благонадежности». В таких системах обычно применяю модель защиты Белл-ЛаПадула (Bell-LaPadula). В настоящее время разработан международный стандарт по классификации уровней безопасности.
Стандарт предусматривает, что элементам данных (вплоть до строки реляционной таблицы) при создании присваиваются метки (security labels), которые образуют иерархию уровней безопасности. Пользователи причисляются к одному из уровней благонадежности и могут видеть только те данные, которые соответствуют их статусу. Уровни безопасности и благонадежности называются классами доступа.
Класс доступа характеризуется двумя компонентами: первый - определяет иерархическое положение класса, второй - представляет собой множество элементов из неиерархического набора категорий, которые могут относиться к любому уровню иерархии.
Например, в табл. 7.1 приведены классы безопасности данных для правительственных и коммерческих организаций США.
Таблица 7.1.
Правительственные Коммерческие
Совершенно секретно Максимальная безопасность
Секретно Ограниченное распространение
Конфиденциальная информация Конфиденциальная информация
Неклассифицированная информация Общедоступная информация
Второй компонент уровня доступа для коммерческой фирмы может включать, например, следующие категории: «недоступно для служащих по контракту», «финансовая информация компании»; «информация об окладах», «исключительно внутри фирмы».
В модели многоуровневой защиты данных создается "решетка", где неирархические компоненты каждого уровня автоматически приписываются всем более высоким уровням (рис. 7.1).
 
Рис.7.1. Решетка классов доступа в модели Белл-ЛаПадула.
Модель имеет два свойства:
1) пользователь может читать данные своего и более низкого уровня;
2) пользователь может записывать данные только своего и более высокого уровня.
Второе свойство помогает избежать проникновения секретных данных на более низкие уровни защиты.
По оценкам экспертов, концепция многоуровневой безопасности в ближайшие годы будет использована в большинстве коммерческих СУБД.Проблемы. Рассмотренная модель защиты информации на практике сталкивается с проблемой многозначного представления одного и того же элемента данных для разных пользователей и проблемой косвенного доступа к секретным данным.
Первая проблема решается с помощью расширения реляционной модели, позволяющего в одной ячейке таблицы хранить не одно значение, а целый набор (для разных уровней доступа).
Вторая проблема состоит в том, что БД может содержать косвенный канал - механизм, посредством которого субъект, обладающий высоким уровнем благонадежности, может предоставлять информацию менее благонадежным субъектам, не прямо (что запрещено моделью безопасности), а косвенно.
Различают два типа косвенных каналов доступа:
- косвенный канал памяти открывается, когда некоторая область памяти ЭВМ используется как средство раскрытия защищенных данных (путем создания выборок из БД и их анализа);
- косвенный канал времени позволяет оценить интенсивность и объем передачи информации в БД. 
Например, данные о конкретном доходах каждого человека являются конфиденциальными, в то время как любому пользователю разрешаются запросы типа “Подсчитать средний доход жителей г.Брянска” (для этого имеются в СУБД агрегатные  функции расчета средних значений, сумм и т.д.). Однако, даже пользуясь только такими функциями,  можно извлечь из базы данных конфиденциальную  информацию путем сравнения нескольких выборок данных. Т.о., разрешая любому пользователю запросы на вычисление агрегатных функций, мы открываем косвенный канал получения секретных данных. Для защиты данных применяют два подхода: во-первых,  ограничивают количество однотипных запросов, что  затрудняет возможность раскрытия  индивидуальных  данных; во-вторых, разрешают  выборку только  по частичному ключу, так как в этом случае никакие арифметические операции не позволят определить значения данных в конкретной записи.
Косвенные каналы времени обычно исключаются за счет соответствующих решений в сфере коммуникаций, например за счет заполняющего трафика, позволяющего замаскировать истинные объемы передаваемой информации
В SQL-3 предусмотрены операторы поддержки безопасности (операторы GRANT и REVOKE), но они не обеспечивают многоуровневой принудительной защиты, а  относятся к средствам добровольного управления доступом. Поэтому коммерческие  СУБД с многоуровневой защитой используют расширения языка SQL для описания уровней доступа.