И множестве других функций СУБД.

Базы данных

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

Такая система должна:

· обеспечивать получение общих и/или детализированных отчетов по итогам работы;

· позволять легко определять тенденции изменения важнейших показателей;

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

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

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

Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).

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

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

· механизмах поиска запрашиваемых данных;

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

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

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

И множестве других функций СУБД.

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

Среди наиболее ярких представителей систем управления базами данных можно отметить (демо): Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Micro-soft SQL Server и Oracle, используемые в приложениях, построенных по техноло-гии «клиент-сервер». Фактически, у любой современной СУБД существует ана-лог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки бо-лее гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.

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

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

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

Термины реляционной модели

Для описания баз данных в реляционной модели говорят не о “таблицах”, “строках” и “столбцах”. Используется целый набор терминов. Фразы вроде “идентификатор есть уникальный атрибут сущности” кажутся абсолютно непонятными; причём строгое обоснование всех этих терминов требует понимания реляционной алгебры. Однако, к счастью, реально все эти термины очень просто связать с обыкновенными таблицами.

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

Название	Автор	Предмет	Класс	Издательство	Год издания	Количество

Строк в этой таблице может быть сколько угодно. Они представляют конкретные книги: каждая строка таблицы отражает одну книгу. В таком случае говорят, что таблица описывает сущность под названием “Книга”; а каждая из строк описывает экземпляр этой сущности. Каждый столбец – это то или иное свойство книги, её атрибут.

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

Итак, три самых важных термина реляционной модели:

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

Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

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

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

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

Сущность	Таблица
Атрибут	Столбец таблицы (поле)
Экземпляр сущности	Строка таблицы (запись)
Связь	Ассоциирование двух или более таблиц

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

Нормализация

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

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

Уникальный идентификатор

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

У каждой сущности должен быть уникальный идентификатор (ключ).

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

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

Свойства атрибута, являющегося ключем:

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

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

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

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

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

На ER-диаграммах названия идентифицирующих атрибутов обычно подчеркивают или помечают звездочкой.

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

О внешних ключах:

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

· Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

При попытке УДАЛЕНИЯ экземпляра сущности, на которую ссылается внешний ключ необходимо определить метод обработки такого события. Например, при удалении поставщика, который осуществил по крайней мере одну поставку. Существует три возможности:

· КАСКАДИРОВАНИЕ – Операция удаления "каскадируется" с тем, чтобы удалить также поставки этого поставщика;

· ОГРАНИЧЕНИЕ – Удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается;

· УСТАНАВЛИВАНИЕ – Для всех поставок удаляемого поставщика внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

ОБНОВЛЕНИЕ первичного ключа сущности, на которую ссылается некоторый внешний ключ может осуществляться похожими методами.

Другие нормальные формы

Кроме рассмотренных в основной части данного занятия первых трех нормальных форм существует еще три нормальных формы: четвертая нормальная форма (4NF), нормальная форма Бойса-Кодда (BCNF) и пятая нормальная форма (5NF), которую иногда называют формой проекции-соединения (PJNF). Для понимания определений этих нормальных форм также необходимо знание понятий реляционной алгебры. Поэтому ограничимся перечислением основных свойств нормальных форм:

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

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

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

 

Индексы

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

Можно проиндексировать сразу несколько столбцов. Например, в таблице “Автор” БД школьной библиотеки имеет смысл проиндексировать столбцы “Фамилия”, “Имя” и “Отчество”, т.к. авторов чаще всего ищут по фамилии, имени и отчеству.

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

 

Нереляционные типы БД

Индустрия СУБД прошла довольно длинный путь, прежде чем появилась реляционная модель. Первые СУБД реализовывали так называемые теоретико-графовые модели.

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

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

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

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

В рамках иерархической модели выделяют язык описания структуры данных – DDL (Data Definition Language), а также язык манипулирования данными – DML (Data Manipulation Language). На сегодняшний день иерархические БД почти не используются.

Еще одна модель БД – сетевая, основанная на обобщенном представлении графа, в котором возможны циклы. Стандарт сетевой модели с описанием ее базовых понятий и формального языка описания был определен в 1975 году организацией CODASYL (Conference of Data System Languages). Сетевая модель гибче иерархической (например, в отличие от иерархической модели, она позволяет моделировать связи “многие-ко-многим”), но отличается более сложным процессом разработки модели.

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

 

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

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

 

Базы данных

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

Такая система должна:

· обеспечивать получение общих и/или детализированных отчетов по итогам работы;

· позволять легко определять тенденции изменения важнейших показателей;

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

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

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

Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).

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

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

· механизмах поиска запрашиваемых данных;

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

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

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

и множестве других функций СУБД.

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

Среди наиболее ярких представителей систем управления базами данных можно отметить (демо): Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Micro-soft SQL Server и Oracle, используемые в приложениях, построенных по техноло-гии «клиент-сервер». Фактически, у любой современной СУБД существует ана-лог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки бо-лее гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.

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

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

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