2 Базы данных и модели представления данных

Для понимания термина «Система Управления Базами Данных» (СУБД) попробуем выяснить сначала:

• 1. Что такое данные?
• 2. Что такое базы данных?

Данные.

Похоже, всякая попытка дать четкое определение термина «данные» не лишена тавтологичности. Рассмотрим несколько таких определений:

Данные — это факты, характеризующие свойства объектов и явлений из некоторой предметной области. Но что такое факты, как не разнообразные данные?

Данные — это информация, предназначенная к обработке. А информация, в свою очередь — это знания о фактических данных.

Данные — это сведения, полученные путем измерения, наблюдения и т. п. Не вдаваясь в дальнейшие семантические изыскания, примем за основу: данные — это информация, факты и сведения. Теперь разберемся, что представляют собой данные с практической точки зрения.

Посмотрев по сторонам: предположим, что мы видим три книжных полки В первой — художественные произведения, во второй — техническая литература, в третьей спит кошка. Что можно сказать об увиденном, где здесь данные? Жанр, наименование, и имена авторов книг, местоположение каждой книги (на первой или второй полке, или вообще вне полок), общее их количество. Стоимость каждой книги, количество страниц. Материал, из которого изготовлена каждая полка, ее габариты. Порода, возраст, вес, имя кошки. Марка ее любимого корма, способность к ловле мышей. На какой из полок предпочитает отдыхать. Данные можно найти везде, они вокруг нас, но не все они представляют интерес с точки зрения их сбора, хранения и обработки. Итак, множество данных описывает свойства каких-либо объектов, принадлежащих выбранной предметной области и взаимоотношения между этими объектами. Для каждого объекта можно определить список его свойств, которые являются существенными. Например, объект «налогоплательщик» с точки зрения налоговых служб может обладать следующими свойствами: имя, дата рождения, доход за предыдущий год и т. п. Конкретный человек, к которому эти данные относятся, имеет гораздо больше свойств — цвет глаз, размер обуви, любимый вид спорта и т. д., но вряд ли они представляют интерес для решения задачи сбора налогов. Тому же самому человеку с точки зрения, например, стоматолога соответствует совершенно иной перечень свойств. Каждое свойство конкретного объекта имеет некоторое значение (цвет глаз — голубой, вес — 78 кг, доход — неизвестен). Набор значений свойств формирует некоторую абстракцию, упрощение этого объекта — мы манипулируем не самим объектом, а ограниченным набором представлений о нем.

Базы данных.

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

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

Банк данных — база данных и система управления ею.

Модели представления данных.

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

Очевидные требования к модели:

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

• * Модель должна допускать автоматическую обработку данных, т. е. должна быть реализуема программными средствами.
• * Модель должна быть наглядной, «прозрачной». Поскольку задача описания структуры данных средствами выбранной модели возлагается на разработчика (человека), чем сложнее модель — тем труднее избежать ошибок при проектировании.

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

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

Сетевая модель. Сетевая модель (рис. 1.1) представляет собой развитие иерархической. Модель позволяет описывать более сложные виды взаимоотношений между данными. Однако расширение возможностей достигается за счет большей сложности реализации самой модели и трудности манипулирования данными.

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

Рис. Реляционная модель.

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

Гибридные модели. В некоторых приложениях предпринимаются попытки смешения различных моделей представления данных. Пример такого смешения — объектно-реляционная модель. В ней использовано некоторое сходство между реляционной и объектной идеологией. Строки таблиц реляционной модели соответствуют объектам объектной модели, столбцы таблиц — атрибутам объектов. Таблицы в целом являются аналогом классов. Отсюда вытекает возможность введения наследования при определении таблиц — таблица-потомок содержит те же столбцы, что и родительская, и, кроме того — дополнительные, определенные при наследовании. По идее создателей, объектно-реляционная модель должна унаследовать от реляционной легкость описания и манипулирования данными, а от объектной — возможность определения более сложных взаимоотношений между объектами.

Реляционные базы данных.

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

Рис. Таблицы в реляционной модели.

В примере (рис. 1.3) показано, как могут быть представлены данные и связи между ними в БД некоторой торговой организации. Таблица «Клиент» содержит данные о каждом клиенте — фамилию, имя и отчество. В таблице «Товар» хранятся сведения об имеющихся товарах. Когда клиент вступает во взаимоотношения с некоторым товаром (делает заказ), этот факт фиксируется в таблице «Заказ». Для того чтобы можно было сослаться на отдельную запись (строку) в некоторой таблице, каждая запись этой таблицы должна содержать уникальный идентификатор. В данном примере роль таких идентификаторов выполняют поля «Id _кл», «Id_тов» и «Id_зак». Поле таблицы, значения которого гарантированно уникальны для каждой записи этой таблицы, называют ключевым полем или ключом. Ключ не обязательно должен быть числовым. Иногда уникальным идентификатором может служить не одно поле, а комбинация полей. При этом сочетание значений этих полей должно быть уникальным. Такие поля образуют составной ключ таблицы.

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

Рис. Изображение таблиц и связей.

Стрелки указывают «направление», в котором используются ключевые поля. Значения из поля «Id _кл» помещаются в поле «Клиент», а значения из поля «Id_тов» — в поле «Товар». Очевидно, что одному клиенту может соответствовать несколько заказов, но каждому заказу соответствует только один клиент. С товарами — аналогичная ситуация. Один товар может входить в несколько заказов, но в каждый заказ входит только один товар.

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

Рис. Преобразованная структура БД.