Лекция №1

Тема: «Введение в базы данных»

Введение

Базы данных стали неотъемлемой частью нашей повседневной жизни.

Система управления базами данных, или СУБД (Database Management System — DBMS), — как программное обеспечение, которое управляет доступом к этой базе данных.

Часть 1. Основные сведения.

 Расчеты с использованием кредитной карточки

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

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

Традиционные файловые системы

Файловые системы. Набор прикладных программ, которые выполняют для

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

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

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

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

спальнями имеют сад и гараж?

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

от центра города?

• Какова средняя арендная плата за квартиру с двумя спальнями?

• Чему равна общая годовая заработная плата всех сотрудников?

• Каким был оборот в прошлом месяце по сравнению с прогнозируемыми по-

казателями в этом месяце?

• Каким будет ожидаемый ежемесячный оборот в следующем финансовом году?

В наше время клиентам, менеджерам и другим сотрудникам с каждым днем

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

Чтобы проиллюстрировать основные принципы такого подхода, рассмотрим его на примере учебного проекта Dreamffome.

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

В ней указываются такие сведения об объекте недвижимости, как адрес и количество комнат, а также информация о владельце. Кроме того, сотрудники отдела реализации обрабатывают запросы от потенциальных арендаторов, каждый из которых должен заполнить форму, подобную представленной на рис. 1.1, б. При помощи сотрудников отдела обработки данных (ОД) сотрудники отдела реализации создали информационную систему для управления данными об аренде недвижимости. Эта система состоит из трех показанных в табл. 1.1-1.3 файлов с данными о недвижимости (PropertyForRent;), владельце (PrivateOwner) и арендаторе (Client). Для простоты изложения опустим детали, относящиеся к сотрудникам компании, различным ее отделениям и владельцам недвижимости, представляющим собой юридические лица.

Сотрудники отдела контрактов отвечают за оформление договоров об аренде недвижимости. Если клиент согласен арендовать некоторый сдаваемый в аренду объект, то одним из сотрудников отдела реализации заполняется форма, показанная на рис. 1.2. В ней указываются все необходимые сведения об арендаторе и сдаваемом в аренду объекте недвижимости. Эта форма передается в отдел контрактов, сотрудники которого присваивают договору номер и вносят дополнительные сведения об оплате и о продолжительности аренды. При помощи сотрудников отдела ОД сотрудники отдела контрактов создали для себя информационную систему учета договорен аренды. Эта система состоит из трех файлов, представленных в табл. 1.4-1.6. Файлы содержат сведения о договорах (Lease), объектах недвижимости (PropertyForRent) и арендаторах (Client), которые во многом сходны с данными в информационной системе отдела реализации.

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

Совершенно очевидно, что очень большое количество данных в отделах дублируется, и это весьма характерно для любых файловых систем. Прежде чем начать обсуждение недостатков этого подхода, было бы полезно познакомиться с терминологией, используемой в файловых системах. Файл является простым набором записей (record), которые содержат логически связанные данные. Например, файл Property ForRent, содержимое которого представлено в табл. 1.1, содержит шесть записей, по одной для каждого сдаваемого в аренду объекта недвижимости. Каждая запись содержит логически связанный набор из одного или нескольких полей (field), каждое из которых представляет некоторую характеристику моделируемого объекта. Из табл. 1.1 видно, что поля файла PropertyForRent представляют такие характеристики сдаваемых в аренду объектов, как адрес, тип объекта и количество комнат.

Рис. 1.З. Схема обработки данных в файловой системе

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

Ограничения, присущие файловым системам

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

·        Дублирование данных

·        Зависимость от данных

·        Несовместимость файлов

·        Фиксированные запросы/быстрое увеличение количества приложений

Дублирование данных

Из-за децентрализованной работы с данными, проводимой в каждом отделе

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

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

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

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

Если сотрудник переедет в другой дом и изменение адреса будет зафиксировано только в отделе кадров, то уведомление о зарплате будет послано ему по старому, т.е. ошибочному, адресу. Более серьезная проблема может возникнуть, если некий сотрудник получит повышение по службе с соот-

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

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

Зависимость от данных

Как уже упоминалось выше, физическая структура и способ хранения запи-

сей файлов данных жестко зафиксированы в коде приложений. Это значит, что

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

• открыть исходный файл Proper Су ForRent для чтения;

• открыть временный файл с новой структурой записи;

• считать запись из исходного файла, преобразовать данные в новый формат

и записать их во временный файл. Эти действия следует выполнить для

всех записей исходного файла;

• удалить исходный файл PropertyForRent;

• присвоить временному файлу имя PropertyForRent.

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

(и описание этих данных), предназначенный для удовлетворения информационных потребностей организации.

Система управления базами данных — СУБД

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

Возможности:

• Позволяет создать базу данных, что обычно осуществляется с помощью языка определения данных (DDL — Data Definition Language). Язык DDL предоставляет пользователям средства указания типа данных и их структуры, а также средства задания ограничений для информации, хранимой в базе данных.

• Позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных, что обычно осуществляется с помощью языка манипулирования данными (DML — Data Manipulation Language). Наличие централизованного хранилища всех данных и их описаний позволяет использовать язык DML как общий инструмент организации запросов,,-который иногда называют языком запросов (query language). Наличие языка запросов позволяет устранить присущие файловым системам ограничения, при которых пользователям приходится иметь дело только с фиксированным набором запросов или постоянно возрастающим количеством программ, что порождает другие, более сложные проблемы управления программным обеспечением.

Наиболее распространенным типом непроцедурного языка является язык структурированных запросов (Structured Query Language — SQL), который в настоящее время определяется специальным стандартом и фактически является обязательным языком для любых реляционных СУБД. (SQL про-

износится либо по буквам "S-Q-L", либо как мнемоническое имя "SeeQuel".)

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

• системы обеспечения защиты, предотвращающей несанкционированный

доступ к базе данных со стороны пользователей;

• системы поддержки целостности данных, обеспечивающей непротиворечивое состояние хранимых данных;

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

• системы восстановления, позволяющей восстановить базу данных до предыдущего непротиворечивого состояния, нарушенного в результате сбоя аппаратного или программного обеспечения;

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

Достоинства:

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

• Предоставляют механизм настройки внешнего интерфейса базы данных. Например, сотрудники отдела контрактов могут работать с полем Monthly rent (Ежемесячная арендная плата), используя для него более короткое и простое имя — rent.

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

Компоненты среды СУБД

Среды СУБД:

·        Аппаратное обеспечение

Программное обеспечение

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

ных программ, вместе с операционной системой, включая и сетевое программное обеспечение, если СУБД используется в сети. Обычно приложения создаются на языках третьего поколения, таких как С, C++, Java, Visual Basic, COBOL, Fortran, Ada или Pascal, или на языках четвертого поколения, таких как SQL, операторы

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

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

Данные

Вероятно, самым важным компонентом среды СУБД (с точки зрения конечных пользователей) являются данные. На рис. 1.6 показано≫ что данные играют роль моста между компьютером и человеком. База данных содержит как рабочие данные, так и метаданные, т.е. "данные о данных". Структура базы данных называется схемой (schema). Показанная на рис. 1.5 схема базы данных состоит из четырех файлов., или таблиц (table): PropertyForRent (Сдаваемый в аренду объект), PrivateOwner (Владелец собственности), Client (Клиент) и Lease

(Договор аренды). Таблица PropertyForRent имеет восемь полей, или атрибу-

тов: propertyNo (Номер объекта), street (Улица), city (Город), postcode

(Почтовый индекс), type (Тип объекта), rooms (Количество комнат), rent

(Ежемесячная арендная плата) и ownerNo (Номер владельца). Атрибут ownerNo

моделирует связь между таблицей PropertyForRent и таблицей PrivateOwner,

т.е. некий владелец владеет (Owns) некой сдаваемой в аренду недвижимостью —как показано на диаграмме "сущность-связь", представленной на рис. 1.4. В частности, из табл. 1.1 и 1.2 следует, что владелец под номером С046, Joe Keogh, владеет недвижимостью под номером РА14.

Процедуры

К процедурам относятся инструкции и правила, которые должны учитываться

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

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

• Регистрация в СУБД.

• Использование отдельного инструмента СУБД или приложения.

• Запуск и останов СУБД.

• Создание резервных копий СУБД.

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

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

·       Пользователи

Администраторы данных и администраторы баз данных

База данных и СУБД являются корпоративными ресурсами, которыми следует управлять так же, как и любыми другими ресурсами. Обычно управление данными и базой данных предусматривает управление и контроль за СУБД и помещенными в нее данными. Администратор данных, или АД {Data Administrator — DA), отвечает за управление данными, включая планирование базы данных, разработку и сопровождение стандартов, прикладных алгоритмов и деловых процедур, а также за концептуальное и логическое проектирование базы данных. АД консультирует и дает свои рекомендации руководству высшего звена, контролируя соответствие общего направления развития базы данных установленным корпоративным целям.

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

Разработчики баз данных

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

• Любой сотрудник не может отвечать одновременно более чем за сто сдаваемых в аренду или продаваемых объектов недвижимости.

• Любой сотрудник не имеет права продавать или сдавать в аренду свою собственную недвижимость.

• Доверенное лицо не может выступать одновременно и как покупатель, и как продавец недвижимости.

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

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

• Логическое проектирование- базы данных, которое проводится с учетом особенностей выбранной модели данных: реляционной, сетевой, иерархической или объектно-ориентированной.

Пользователи

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

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

1.6. Преимущества и недостатки СУБД

Преимущества:

·        Контроль за избыточностью данных

·        Непротиворечивость данных

·        Больше полезной информации при том же объеме хранимых данных

·        Совместное использование данных

·        Поддержка целостности данных

·        Повышенная безопасность

·        Применение стандартов

·        Повышение эффективности с ростом масштабов системы

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

·        Повышение доступности данных и их готовности к работе

·        Улучшение показателей производительности

·        Упрощение сопровождения системы за счет независимости отданных

·        Улучшенное управление параллельной работой

·        Развитые службы резервного копирования и восстановления

Недостатки:

·        Сложность

·        Размер

·        Стоимость СУБД

·        Дополнительные затраты на аппаратное обеспечение

·        Затраты на преобразование

·        Производительность

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