Базы данных 1 лекция лаб 1

1

Введение в базы данных

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

Типы СУБД

Системы управления базами данных (СУБД) — это программные средства, предназначенные для создания, наполнения, обновления и удаления баз данных. Различают три основных вида СУБД: промышленные универсального назначения, промышленные специального назначения и разрабатываемые для конкретного заказчика.

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

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

Заказные СУБД в максимальной степени учитывают специфику работы.

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

Рис. 1.1. Архитектура СУБД: однозвенная (слева); двухзвенная (в центре); трехзвенная (справа)

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

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

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

2

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

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

например, Microsoft SQL Server производства корпорации Microsoft, Sybase SQL Server корпорации Sybase, Oracle

производства одноименной корпорации1, DB2 корпорации IBM и т. д. SQL-сервером является также и сервер InterBase корпорации Borland, который поставляется вместе с Delphi 7 Studio в комплектациях Enterprise и Architect.

Распределенные СУБД могут содержать несколько десятков и сотен серверов БД. Обычно такие СУБД работают на предприятиях государственного масштаба. К ним относятся подразделения Министерства обороны и Министерства внутренних дел.

Таблицы БД и связи между ними

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

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

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

Связанные отношениями таблицы взаимодействуют по принципу главная {master) — детальная (detail)*. В нашем примере таблица отпуска товаров — главная, а таблица покупателей — детальная. Главную таблицу часто называют родительской, а детальную — дочерней. Одна и та же таблица может быть главной по отношению к одной таблице БД и дочерней по отношению к другой.

Связи между таблицами базы данных

В БД существуют три типа отношений между различными множествами объектов :

один к одному,

один ко многим,

многие ко многим.

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

Отношение «один ко многим» рассмотрено в приведенном примере. Здесь один покупатель может сделать несколько заказов, но у одного заказа существует лишь один покупатель. Отношение «один ко многим» вызывает избыточность информации. Она устраняется организацией отдельной таблицы для каждого множества объектов (Таблица Покупателей и Таблица Заказов).

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

3

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

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

Первичные ключи облегчают установление связи между таблицами. В таблице покупателей таким ключом может быть одноименное поле. Установив связь по первичному ключу, мы можем выяснить, что, например, 10.12.99 со склада было отпущено 100 единиц книг «Borland С++ Builder 4» покупателю «Магазин № 1», который расположен по адресу: 107005, Москва, 2-я Бауманская ул., 12 (телефон для связи 273-00-14).

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

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

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

Дата Название книги Покупатель Отпущено

10.12.99 Borland С++ Builder 4 1 100 10.12.99 Delphi 5. Учебный курс 1 100 12.12.99 В сетях Всемирной паутины 2 2000

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

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

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

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

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

Механизм BDE

Характерной особенностью программ, созданных с помощью Delphi и предназначенных для работы с базами данных, является их зависимость от специальной библиотеки программ, которая называется BDE (Borland Database Engine — машина баз данных корпорации Borland). BDE представляет собой набор библиотек DLL, предназначенных для низкоуровнего доступа к данным самых различных форматов. BDE автоматически устанавливается в процессе установки Delphi и регистрируется в реестре 32-разрядной версии Windows. BDE «умеет» работать с таблицами самых распространенных СУБД, причем как файл-серверных (dBase, Paradox, FoxPro, Clipper), так и клиент-серверных (InterBase, Microsoft SQL Server, Oracle и др.). В BDE имеется собственный интерпретатор языка SQL, что позволяет создавать запросы не только к серверам БД, но и таблицам файл-сервера.

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

4

Проектирование БД

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

Имена таблиц и полей

В файл-серверных БД имя таблицы совпадает с именем файла, в котором размещаются все содержащиеся в ней данные. В именах полей полезно ставить префикс из одной-двух букв названия таблицы (в таблице NAKLS все имена начинать с буквы «N», в FIRMS — с «F» и т. п.). Старайтесь делать имена полей по возможности лаконичными

— это сократит код программы и сроки ее создания.

Создание таблиц

В файл-серверных БД все таблицы размещаются в одном каталоге (папке). Создание таблиц файл-серверных БД осуществляется с помощью утилиты (вспомогательной программы) Database Desktop (DBD), входящей в комплект поставки Delphi.

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

Запустите DBD с помощью команды Пуск ► Программы ► Borland Delphi 7 ► Database Desktop (если вы работаете в среде Delphi, для запуска используйте команду Tools ► Database Desktop главного меню).

Первое, что необходимо сделать, — это настроить рабочий каталог утилиты. Выберите команду File ► Working Directory и установите в появившемся окне ссылку на каталог C:\BIBLDATA (рис. 1.3).

Для создания таблицы NAKLS выберите команду File ► New ► Table. DBD откроет окно Create Table, в котором можно выбрать тип таблицы. Тип таблицы определяет многие ее свойства. Тип Paradox 7 можно считать наилучшим для файл-серверных таблиц: щелчком на кнопке ОК согласитесь с вариантом Paradox 7, предложенным по умолчанию. На экране появится окно (рис. 1.4), предназначенное для создания/редактирования структуры таблицы.

Рис. 1.3. Установка рабочего каталога

Рис. 1.4. Окно создания структуры таблицы

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

Введите название первого поля Naklld (первый символ названия поля для таблиц Paradox DBD всегда вводится прописным) и нажмите клавишу табуляции для перехода к следующей колонке, в которой вводится тип поля. Нажмите клавишу пробела, чтобы утилита DBD показала список возможных типов, и выберите в нем тип Autoincrement. Поля автоинкрементного типа служат для создания уникального числа, однозначно определяющего запись: для первой записи в это поле будет автоматически помещено число 1, для второй — 2 и т. д. При удалении какой-либо записи

5

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

Продолжите ввод полей таблицы NAKLS так, как показано на рис. 1.5. Для первых четырех полей установите флажок Required Field, означающий, что при вводе очередной записи в эти поля обязательно должны быть помещены значения — за этим будет следить BDE. Четыре других поля могут не определяться в момент ввода очередной записи. Имеет смысл определить для них значения по умолчанию в строке Default value: для поля NCoeff таким значением будет 1, для остальных — 0.

По полю NDate нужно определить индекс (в терминологии таблиц Paradox он называется вторичным). Для этого раскройте список Table properties в правом верхнем углу окна, выберите пункт Secondary Indexes и щелкните на появившейся кнопке Define. В окне Define Secondary Index (рис. 1.6) в списке полей таблицы выделите (щелчком) поле NDate и затем щелкните на кнопке со стрелкой вправо, чтобы перенести поле в список Indexed fields. Замечу, что таким способом можно перенести не одно, а несколько полей. Индекс, построенный по нескольким полям, называется

составным.

Рис. 1.5. Структура полей таблицы NAKLS

Рис. 1.6. Определение индексного поля (полей)

Спомощью флажков группы Index options можно определить следующие особенности индекса:

•Unique — индекс будет содержать уникальные значения;

•Maintained — индексные поля сортируются по возрастанию значений;

•Case sensitive — индекс чувствителен к регистру букв в текстовых полях;

•Descending — индексные поля сортируются по убыванию значений.

В нашем случае (а также при определении индексов в других таблицах демонстрационной БД) оставьте эти флажки без изменений и щелкните на кнопке ОК. DBD запросит имя индекса (в таблицах Paradox, как и в большинстве серверов БД, индексы именуются) — введите строку Nakls_date и щелкните на кнопке ОК. Во вновь появившемся окне определения структуры таблицы щелкните на кнопке Save as и затем укажите имя файла — Nakls.

Мы только что создали структуру таблицы NAKLS.

Свойства таблиц Paradox 7

Как уже говорилось, тип таблиц Paradox 7 предпочтителен при создании файл-серверных БД. Таблицы Paradox 7 по сравнению с другими поддерживают самый богатый набор разных типов полей, что позволяет автоматически следить за правильностью вводимых в поля данных (пункт Validity Checks в списке Table properties), выбирать данные из другой таблицы (Lookup Table), строить вторичные индексы, в том числе составные (Secondary Indexes), следить за ссылочной целостностью БД (Referential Integrity), защищать таблицу от несанкционированного доступа (Password Security), выбирать языковый драйвер (Table Language).

Типы полей

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

ки таблицы Field roster DBD.

Таблица 1.1. Типы данных в таблицах Paradox

9

Очистите свойство Caption у самой нижней панели и поместите на нее кнопки навигатора БД TDBNavigator (вкладка Data Controls) и кнопку TBitBtn (вкладка Additional). Навигатор расположите у левого края панели, а кнопку

— у правого. Раскройте список свойства Anchors кнопки и выровняйте навигатор по правому краю: поместите False в свойство akLef t и True в свойство akRight. В свойство Kind кнопки поместите значение bkClose. Вид окна к этому моменту показан на рис. 1.12.

Сохраните все сделанные вами изменения модуля главной формы на диске.

Создание псевдонима БД

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

С помощью команды Database ► Explorer из среды Delphi запустите утилиту SQL Explorer, на вкладке Databases открывшегося окна щелкните правой кнопкой мыши на узле Database и выберите команду New в контекстном меню. Утилита предложит выбрать тип вновь создаваемого псевдонима. Согласитесь с вариантом Standard, предлагаемым по умолчанию, — псевдонимы именно этого типа предназначены для обслуживания файл-серверных БД с таблицами Paradox (рис. 1.13).

Рис. 1.13. Определение псевдонима

Сразу после этого появится имя псевдонима STANDARD 1, предлагаемое по умолчанию, и на вкладке Definition будут перечислены его свойства. Воспользуемся тем, что выделено имя STANDARD 1, и сразу заменим его именем BIBLDATA. Теперь перейдите на вкладку Definition и в пустом поле справа от свойства PATH введите путь доступа к файлам БД: С: \BIBLDATA. Щелкните на вновь созданном псевдониме на вкладке Databases правой кнопкой мыши и выберите команду Apply в контекстном меню. В появившемся после этого диалоговом окне подтвердите необходимость запомнить вновь созданный псевдоним.

Если теперь на вкладке Databases щелкнуть на значке свернутого узла слева от имени псевдонима, а затем — на значке свернутого узла Tables, вы увидите все таблицы БД «Книголюб». Щелкнув на любой из них и открыв вкладку Data, вы сможете увидеть содержимое выбранной таблицы (рис. 1.14).

Рис. 1.14. Отображение содержимого таблицы в окне SQL Explorer

Модуль данных

В программе нам понадобятся 5 компонентов ТТаble и два компонента TDataSource. Разместим их в отдельном модуле данных, чтобы эти компоненты не загромождали основное окно.

10

Выберите команду File ► New ► Others, чтобы открыть окно хранилища объектов, и на вкладке New открывшегося окна дважды щелкните на значке Data Module. В свойство Name модуля данных поместите значение DM и сохраните модуль в файле dmNaklsU. Чтобы связать модуль с проектом, щелкните на копке панели инструментов и выберите только что созданный файл dmNakl sU.

Для связи таблиц с БД воспользуемся компонентом TDatabase на вкладке BDE палитры компонентов Delphi: щелкните на нем и затем — на имени модуля DM в окне дерева объектов. В окне инспектора объектов раскройте список свойства AliasName и выберите псевдоним BIBLDATA. В строке свойства DatabaseName напишите произвольное имя (например, AAA) так называемого локального псевдонима, который создает компонент TDatabase.

Локальный псевдоним доступен только в той программе, в которой используется компонент TDatabase. Этот компонент выполняет множество полезных функций, обеспечивающих связь программы с БД. Для файл-серверных систем только с его помощью можно реализовать транзакции — специальный механизм доступа к данным, повышающий их достоверность и непротиворечивость. В клиент-серверных системах он, кроме того, способен передать серверу БД имя пользователя, его пароль и ряд других параметров, оптимизирующих связь с сервером и избавляющих пользователя программы от обязательной регистрации на сервере.

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

Теперь перенесите в окно дерева объектов компонент ТТаblе (вкладка BDE) и «положите» его на псевдоним AAA. В окне инспектора объектов в свойстве DatabaseName нового компонента автоматически появится имя локального псевдонима AAA, однако слева от компонента в окне дерева объектов будет красный знак вопроса, означающий, что компонент ТТаЫе еще не готов к работе.

Компонент ТТаble является набором данных (НД). Он преимущественно используется в файл-серверных системах для доступа к данным из какой-либо одной таблицы БД. Чтобы подготовить компонент к работе, необходимо определить имя этой таблицы: раскройте список его свойства TableName и выберите в нем таблицу NAKLS. В дальнейшем нам придется много раз обращаться к методам и свойствам этого компонента, поэтому измените его имя Table 1, заданное по умолчанию, на имя связанной с ним таблицы: в строке свойства Name введите Nakls.

Чтобы данные из НД Nakls смогла отобразить сетка DBGridl в главном окне программы, ее нужно связать с НД с помощью специального компонента TDataSource: выделите его на вкладке Data Access палитры компонентов и затем щелкните на компоненте Nakls в окне дерева объектов, чтобы связать его с НД.

Теперь подготовим вторую пару ТТаblе — TDataSource для отображения данных из таблицы MOVEBOOK во второй сетке главного окна: «положите» на псевдоним AAA набор данных ТТаЫе, а на него — источник данных TDataSource; свяжите НД с таблицей MOVEBOOK и дайте ему имя Move. Вид модуля данных к этому моменту показан на рис. 1.15.

Наборы данных Na kl s и Move связаны реляционным отношением один ко многим: единственной записи (накладной) в первом НД может соответствовать произвольное количество записей (книг) во втором. Чтобы НД «знали» об этом и согласованно отображали данные, их нужно предварительно подготовить. Перейдите на вкладку Diagram в окне кода модуля данных (предварительно нажмите клавишу F12 для визуализации окна кода) и с помощью мыши «перетащите» компоненты Nakls и Move из окна дерева объектов на вкладку Diagram. Перетаскивание реализуется классическим способом Drag&Drop: левая кнопка мыши нажимается на компоненте в окне дерева объектов и остается нажатой при перемещении указателя мыши на вкладку Diagram, после чего отпускается. Расположите таблицы Diagram одну под другой так, как это показано на рис. 1.16.

Рис. 1.15. Окно модуля данных с двумя наборами данных и окно дерева объектов