Ассess_тема1_общие_свед_БД_

ТЕМА 1. ОБЩИЕ СВЕДЕНИЯ О БД

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

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

Но данные – это абстракция; никто никогда не видел "просто данные"; они не возникают и не существуют сами по себе. Данные – это отражение объектов реального мира. Пусть, например, требуется хранить сведения о деталях, поступивших на склад. Как объект реального мира – деталь – будет отображена в базе данных? Для ответа на этот вопрос, необходимо знать, какие признаки или стороны детали будут актуальны, необходимы для работы. Среди них могут быть название детали, ее вес, размеры, цвет, дата изготовления, материал, из которого она сделана и т.д. В традиционной терминологии объекты реального мира, сведения о которых хранятся в базе данных, называются сущностями, а их актуальные признаки — атрибутами.

Каждый признак конкретного объекта есть значение атрибута. Так, деталь "двигатель" имеет значение атрибута "вес", равное "50", что отражает тот факт, что данный двигатель весит 50 килограммов.

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

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

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

Таким образом, в широком смысле слова база данных — это

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

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

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

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

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

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

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

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

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

Однако иерархическая модель не всегда удобна:

1)при моделировании событий, как правило, необходимы связи типа "многие ко многим";

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

A

B		C

F		D		D		E

дублирование

A

		B				C
			не допускается
F				D				E

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

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

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

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

"Cronos Plus".

По распространенности и популярности реляционные СУБД сегодня – вне конкуренции. Они стали фактическим промышленным стандартом.

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

Эдгар Кодд, сотрудник исследовательской лаборатории корпорации IBM в Сан-Хосе, по существу, создал и описал концепцию реляционных баз данных в своей основополагающей работе «Реляционная модель для крупных, совместно используемых банков данных» (A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, июнь 1970). Кодд предложил модель, которая позволяет разработчикам разделять свои базы данных на отдельные, но взаимосвязанные таблицы, что увеличивает производительность, но при этом внешнее представление остается тем же, что и у исходной базы данных. С тех пор Кодд считается отцом-основателем отрасли реляционных баз данных.

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

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

– это совокупность значений конкретного атрибута объекта. Так, столбец Материал представляет собой множество значений "Сталь", "Олово", "Цинк", "Никель" и т.д. В столбце Количество содержатся целые неотрицательные числа. Значения в столбце Вес — вещественные числа, равные весу детали в килограммах.

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

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

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

Рисунок 1. Основные понятия базы данных.

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции – среди них не существует "первой", "второй", "последней". Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key).

Индекс - это отсортированный список значений полей, предназначенный для ускорения поиска в базе данных.

Интересны, как правило, не все индексы, а уникальные индексы.

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

Первичный ключ (primary key) представляет собой один из примеров уникальных индексов и применяется для уникальной идентификации записей таблицы. Никакие из двух записей таблицы не могут иметь одинаковых значений первичного ключа. Первичный ключ обычно сокращенно обозначают как PK (primary key).

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

Если таблица удовлетворяет этому требованию, она называется отношением

(relation).

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

Рисунок 2. Взаимосвязь таблиц базы данных.

Первичный ключ таблицы Руководитель – столбец Номер_рук (например, табельный номер). Столбец Фамилия не может выполнять роль первичного ключа, так как в одной организации могут работать два руководителя с одинаковыми фамилиями. Любой сотрудник подчинен единственному руководителю, что должно быть отражено в базе данных. Таблица Сотрудник содержит столбец Номер_ рук, и значения в этом столбце выбираются из столбца Номер_рук таблицы Руководитель (см. рис. 2). Столбец Номер_рук является внешним ключом в таблице Сотрудник.

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

идентифицирует один объект. Отношение между объектами определяет отношение между таблицами. Существует 4 типа отношений:

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

Отношение «один-ко-многим» означает, что каждой записи в одной таблице соответствует одна или несколько записей в другой таблице.

Отношение «многие-ко-одному» аналогично рассмотренному ранее типу. Тип отношения между объектами зависит от вашей точки зрения.

Отношение «многие-ко-многим» возникает между двумя таблицами в тех случаях,

когда:

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

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

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

Почти все современные СУБД основаны на реляционной модели данных.

В качестве примера можно привести реляционные СУБД MS SQL Server и MS Access, InterBase и FoxPro, PostgreSQL и Paradox.

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

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

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

Но объектно-ориентированные базы данных являются навигационными, что является шагом назад.

Причиной появления систем объектно-ориентированных баз данных была потребность в более адекватном представлении и моделировании сущностей реального мира, поскольку ООБД обеспечивают гораздо более развитую модель данных, нежели традиционные — реляционные базы данных. Парадигма ООБД основывается на ряде базовых понятий, таких как объект, идентифицируемость, класс, наследование, перегрузка и отложенное связывание [2, 3, 23, 31, 36].

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

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