Модели данных

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

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

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

Данные, хранящиеся в БД, должны быть организованы по определенным правилам.

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

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

Иерархическая модель данных

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

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

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

Совокупность конкретных значений полей сегмента называется экземпляром сегмента илизаписью: г. Амурск – ул. Победы, 3 – 18-67-53. Следовательно, один блок на схеме отображает множество фактических записей (экземпляров сегмента).

Рис. 2. Иерархическая база данных

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

Основные свойства иерархической модели данных.

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

2. Между сегментами двух уровней могут поддерживаться только связи «один ко многим» (один филиал – много магазинов, один склад – много товаров) или «один к одному» (один филиал – один директор).

Недостатки иерархической модели данных:

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

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

3. Жесткость структуры, не позволяющая учесть в базе данных отдельные реальные ситуации. Например, товары, хранящиеся на одном складе, предназначены нескольким магазинам.

4. Сложность эксплуатации. Работа с иерархическими базами данных требует значительной квалификации пользователей в области программирования. В частности, в СУБД IMS фирмы IBM для описания общей схемы базы данных и блока связи каждого пользователя с базой данных использовался язык программирования Assembler. Для выборки данных из БД – специализированный язык DL/1, для обработки полученной информации – языки PL/1 или Кобол.

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

Сетевая модель данных

Стандарт сетевой модели данных впервые был определен в 1975 г. организацией CODASYL (Conference of Data System Languages).

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

Рис. 3 Сетевая база данных

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

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

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

По указанным причинам СУБД, построенные на основе сетевой модели (IDMS, db_VistaIII и др.), не получили широкого распространения [ 15 ].

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

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

Реляционная модель ориентирована на организацию данных в виде таблиц (отношений).

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

Каждая таблица реляционной базы данных имеет имя и строку заголовков.

Рассмотрим таблицу базы данных торгового предприятия, в которой хранятся сведения о поставщиках товаров (табл. 1.1):

Таблица 1.1

Поставщики

Код	Название	Город
	Волна	Хабаровск
	Парус	Владивосток
	Звезда	Хабаровск
	Парус	Иркутск

Таблица имеет имя Поставщики, названия столбцов таблицы Код, Название, Город представляют собой строку заголовков.

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

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

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

К таблицам РМД предъявляются следующие требования:

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

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

3. Порядок следования записей может быть произвольным.

4. В таблице не должно быть одинаковых записей.

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

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

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

Таблица 1.2

Поставки товаров

Название товара	Артикул	Количество	Дата поставки	Шифр поставщика
Костюм			10.12.05
Сапоги			10.12.05
Туфли			11.12.05
Костюм			11.12.05
Костюм			12.12.05
Костюм			12.12.05
Туфли			12.12.05

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

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

Предположим, в таблице Дополнительные сведения хранится подробная информация об организациях, поставляющих товары (табл. 1.3):

Таблица 1.3

Дополнительные сведения

Поставщик	Директор	Телефон	Адрес	№ договора
	Иванов П. Л.	64-12-83	Мира, 4
	Сеидов О. А.	22-17-12	Победы, 18
	Цой О. М.	39-18-34	Блюхера, 1
	Лодис С. С.	46-19-23	Пушкина, 1

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

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

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

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

С помощью связывания таблиц Поставщики и Поставки товаров по ключевым полям, можно получить ответы на запросы: «Какая организация поставила костюмы 10 декабря 2005 г.?» (Волна); «Из каких городов были привезены туфли?» (Хабаровск, Иркутск).

Связывая таблицы Поставки товаров и Дополнительные сведения, можно получить ответы на запросы: «Какой номер телефона у организации, поставившей костюмы с артикулом 500?» (64-12-83); «В соответствии с каким договором поставлялись костюмы с артикулом 400?» (№ 35).

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

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

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

Создание объектно-ориентированных СУБД считается одним из наиболее перспективных направлений в области разработки новых типов баз данных.

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

Объект обладает следующими характеристиками [ 12 ]:

1. Имеет уникальный идентификатор, однозначно определяющий объект.

2. Принадлежит к некоторому классу, обладающему определенными поведением и свойствами.

3. Может обмениваться сообщениями с другими объектами.

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

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

В объектно-ориентированной модели возможно создание нового класса объектов на основе уже существующего класса. Этот процесс называется наследованием. Новый класс, называемый подклассом существующего класса (суперкласса), наследует все свойства и методы суперкласса [ 4 ]. Кроме того, для него могут быть определены дополнительные свойства и методы.

Объектно-ориентированная СУБД позволяет хранить объекты и обеспечивает их совместное использование различными приложениями. Для этого она должна обладать следующими компонентами [ 12 ]:

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

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

Для практической реализации объектно-ориентированных баз данных применяются два подхода [ 12 ]:

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

2. Основой является реляционная система, к которой добавляются объектно-ориентированные компоненты.

Недостатки объектно-ориентированных баз данных [ 12 ]:

1) отсутствуют необходимое унифицированное теоретическое обоснование и стандартизованная терминология;

2) не существует формально сформулированной методологии проектирования баз данных;

3) отсутствуют средства создания нерегламентированных запросов;

4) нет общих правил поддержания согласованности данных.

В заключение можно отметить, что объектно-ориентированные базы данных в настоящее время очень сложны в проектировании и эксплуатации, что ограничивает их практическое применение. Поэтому, несмотря на продолжающиеся интенсивные исследования, объектно-ориентированная модель данных пока поддерживается лишь немногими СУБД (POET, Jasmine, Versant, Iris) [ 15 ].

10.Язык SQL – функции запросов и основные возможности.

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

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

- предложения определения данных (определение баз данных, а также определение и уничтожение таблиц и индексов);

- запросы на выбор данных (предложение SELECT);

- предложения модификации данных (добавление, удаление и изменение данных);

- предложения управления данными (предоставление и отмена привилегий на доступ к данным, управление транзакциями и другие).

Введение[править | править исходный текст]

SQL является прежде всего информационно-логическим языком, предназначенным для описания, изменения и извлечения данных, хранимых в реляционных базах данных. SQL нельзя назвать языком программирования ^{[ источник не указан 975 дней ] [5]}.

Изначально SQL был основным способом работы пользователя с базой данных и позволял выполнять следующий набор операций:

· создание в базе данных новой таблицы;

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

· изменение записей;

· удаление записей;

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

· изменение структур таблиц.

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

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

Каждое предложение SQL — это либо запрос данных из базы, либо обращение к базе данных, которое приводит к изменению данных в базе. В соответствии с тем, какие изменения происходят в базе данных, различают следующие типы запросов:

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

· запросы на получение данных;

· запросы на добавление новых данных (записей);

· запросы на удаление данных;

· обращения к СУБД.

Основным объектом хранения реляционной базы данных является таблица, поэтому все SQL-запросы — это операции над таблицами. В соответствии с этим, запросы делятся на:

· запросы, оперирующие самими таблицами (создание и изменение таблиц);

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

Каждая таблица описывается в виде перечисления своих полей (столбцов таблицы) с указанием

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

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

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

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

· вставка новой строки;

· изменение значений полей строки или набора строк;

· удаление строки или набора строк.

Самый главный вид запроса — это запрос, возвращающий (пользователю) некоторый набор строк, с которым можно осуществить одну из трёх операций:

· просмотреть полученный набор;

· изменить все записи набора;

· удалить все записи набора.

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

Описание[править | править исходный текст]

Язык SQL представляет собой совокупность

· операторов,

· инструкций,

· и вычисляемых функций.

Операторы[править | править исходный текст]

Согласно общепринятому стилю программирования, операторы (и другие зарезервированные слова) в SQL всегда следует писать прописными буквами.^[6]

Операторы SQL делятся на:

· операторы определения данных (Data Definition Language, DDL):

· CREATE создает объект БД (саму базу, таблицу, представление, пользователя и т. д.),

· ALTER изменяет объект,

· DROP удаляет объект;

· операторы манипуляции данными (Data Manipulation Language, DML):

· SELECT считывает данные, удовлетворяющие заданным условиям,

· INSERT добавляет новые данные,

· UPDATE изменяет существующие данные,

· DELETE удаляет данные;

· операторы определения доступа к данным (Data Control Language, DCL):

· GRANT предоставляет пользователю (группе) разрешения на определенные операции с объектом,

· REVOKE отзывает ранее выданные разрешения,

· DENY задает запрет, имеющий приоритет над разрешением;

· операторы управления транзакциями (Transaction Control Language, TCL):

· COMMIT применяет транзакцию,

· ROLLBACK откатывает все изменения, сделанные в контексте текущей транзакции,

· SAVEPOINT делит транзакцию на более мелкие участки.

Преимущества и недостатки[править | править исходный текст]

Преимущества[править | править исходный текст]