Теория реляционных баз данных
ПРОГРАММИРОВАНИЕ В СРЕДЕ DELPHI 6
Часть 2
Базы данных. Создание отчета с помощью Word.
Потоки
Утверждено Редакционно-издательским советом
университета в качестве лабораторного практикума
Воронеж 2004
УДК 681.3
Воробьёв Э.И., Короткевич Д.Э.. Программирование в среде Delphi 6: Лабораторный практикум: Ч. 2: Базы данных. Создание отчета с помощью Word. Потоки. Воронеж: Воронеж. гос. техн. ун-т, 2004. 107 с.
Во второй части лабораторного практикума рассматриваются теоретические и практические сведения для написания программ в среде Delphi 6 на тему: «Проектирование баз данных, создание отчетов в программе Word и использование потоков при создании высокопроизводительных приложений».
Издание соответствует требованиям Государственного образовательного стандарта высшего профессионального образования по направлению 230100 «Информатика и вычислительная техника», специальности 230104 «Системы автоматизированного проектирования», дисциплине «Программирование на языках высокого уровня».
Табл. 3. Ил. 19. Библиогр.: 7 назв.
Научный редактор: д-р техн. наук, проф. Я.Е. Львович
Рецензенты: кафедра вычислительной техники Воронеж- ской лесотехнической академии (зав. кафедрой д-р техн. наук, проф. В.Е. Межов);
д-р техн. наук, проф. О.Ю.Макаров
© Воробьёв Э.И., Короткевич Д.Э., 2004
© Оформление. Воронежский государственный
технический университет, 2004
Введение
Концепция баз данных
Базы данных считаются основным преимуществом Delphi. Даже специализированные языки для работы с базами данных (такие, как MS Visual FoxPro) явно уступают по простоте и мощи программирования этого типа приложений. Delphi скрывает все сложности и в то же время даёт величайшую мощь. Ещё не было такой задачи, которую не смогли бы реализовать на Delphi за короткий промежуток времени. А главное, что всё это реализовано очень удобно и легко для понимания. В Delphi можно создавать простые приложения, даже со сложными базами, без единой строчки кода. В данном учебном пособии рассмотрены лабораторные задания для освоения приемов работы с локальными базами данных.
Теория реляционных баз данных
Ещё десять лет назад программирование баз данных было очень сложным занятием. Сейчас уже такое трудно себе представить, потому что благодаря Delphi процесс написания программ упростился, а количество разновидностей баз данных уже исчисляется десятками.
Базы данных делятся на локальные (установленные на компьютере клиента, там же где и работает программа) и удалённые (установленные на сервере, удалённом компьютере). Серверные базы данных располагаются на удалённом компьютере и работают под управлением серверного программного обеспечения. К их главным преимуществам можно отнести возможность работы с одной базой данных одновременно несколькими пользователями, и при этом осуществляется минимальная нагрузка на сеть. Есть ещё сетевые базы данных, которые создают слишком большую нагрузку на сеть и неудобны в работе как для программиста, так и для конечного пользователя. Когда программа присоединяется к сетевой базе данных, то она выкачивает с сервера практически полную его копию. Если Вы внесли изменения, то Ваша копия полностью закачивается обратно. Это очень неудобно, потому что создаётся большая нагрузка на сеть из-за излишней перекачки данных. При клиент-серверной технологии программа клиент посылает простой текстовый запрос на сервер на получение каких-либо данных. Сервер обрабатывает его и возвращает только необходимую порцию данных. Когда нужно изменить какие-то данные опять посылается запрос к серверу на их изменение, и сервер изменяет данные в своей базе. Таким образом, по сети происходит перекачка в основном только текстовых запросов, которые в основном занимают меньше килобайта. Все данные обрабатывает сервер, а значит, машина клиента загружается намного меньше и не так сильно требовательна к ресурсам. Сервер отсылает клиенту только самые необходимые данные, а значит, отсутствует излишняя перекачка копии всей базы. Благодаря всему этому сетевые базы данных уже устарели и практически не используются. Их практически полностью вытесняет технология клиент-сервер. А вот локальные базы данных будут жить всегда. Может измениться формат их хранения или добавиться какие-то новые функции, но сами базы данных будут существовать. Для дальнейшего рассмотрения нам надо определить новое понятие – таблица. Пока что говорились только общие принципы, поэтому использовалось общее понятие баз данных. Таблица базы данных – это как двухмерный массив, в котором в столбец выстроены данные (яркий пример таблицы – Excel). База данных – грубо говоря, это всего лишь файл, в котором может храниться от одной до нескольких таблиц. Большинство локальных баз данных могут хранить только одну таблицу (dBase, Paradox, XML). Но есть представители локальных баз, где в одном файле заключено несколько таблиц (например Access).
Локальные базы данных
Из локальных баз данных рассмотрим реляционные как самые распространённые. Что такое реляционная база данных? Это таблица, в которой в качестве столбцов выступают имена хранимых в ней данных, а каждая строка хранит сами данные. Таблица базы данных похожа на электронную таблицу Excel (если быть точнее, то Excel хранит свои данные в виде собственного формата, построенного на основе технологии баз данных). Локальные таблицы баз данных могут храниться на локальном жёстком диске или централизовано сохраняться на сетевой диск файлового сервера. Эти файлы можно копировать с помощью стандартных средств как любой другой файл, потому что сами таблицы базы данных не привязаны к определённому месту расположения. Главное, чтобы программа могла найти таблицу. В каждой таблице должно быть одно уникальное поле, которое однозначно будет идентифицировать строку. Это поле называется ключевым. Эти поля очень часто используются для связывания нескольких таблиц между собой. Но даже если таблица не связана, ключевое поле всё равно обязательно. В качестве ключа желательно использовать численный тип и если позволяет база данных, то будет лучше если он будет типа "autoincrement" (автоматически увеличивающееся/уменьшающееся число или счётчик). Имена столбцов в таблице базе данных также должны быть уникальными, но в этом случае не обязательно числовыми. Их можно называть как угодно, лишь бы было уникально и понятно. Каждый столбец (поле базы данных) обязательно должен иметь определённый тип. Количество типов и их разновидности зависят от типа базы данных, например формат dBASE (файлы с расширением DBF) поддерживает только 6 типов, а Paradox уже до 15. База данных может храниться в одном файле (Access) или в нескольких (Paradox, dBase). Точнее сказать, данные таблицы всегда хранятся в одном файле, а вот дополнительная информация может располагаться в отдельных файлах. В качестве дополнительной информации могут быть индексы, ограничения или список значений по умолчанию для конкретных полей. Если хотя бы один из файлов запортится или будет удалён, то данные могут стать недоступными для редактирования.
Что такое индексы? Очень часто данные из таблиц подвергаются каким-то изменениям, поэтому прежде чем произвести редактирование над какой-либо строкой, необходимо её найти. Даже статические таблицы, использующиеся в качестве справочников, тоже подвергаются операциям поиска перед выводом запрашиваемых данных. Поиск достаточно трудоёмкая операция, особенно если таблица содержит очень много строк. Индексы направлены на ускорение этой процедуры, а так же могут использоваться в качестве отправной точки при сортировке. На данном этапе достаточно знать, что не проиндексированное поле невозможно упорядочить.
Если надо, чтобы какая-то таблица была упорядочена по полю «Фамилия», то это поле надо сначала проиндексировать. Затем нужно только указать, что таблица должна работать сейчас с таким-то индексом, и она сортируется автоматически.
В хорошо спроектированной базе данных избыточность данных исключается, и вероятность сохранения противоречивых данных минимизируется. Таким образом, создание баз данных преследует две основные цели: понизить избыточность данных и повысить их надежность.
Жизненный цикл любого программного продукта, в том числе и системы управления базой данных, состоит (по-крупному) из стадий проектирования, реализации и эксплуатации.
Естественно, наиболее значительным фактором в жизненном цикле приложения, работающего с базой данных, является стадия проектирования. От того, насколько тщательно продумана структура базы, насколько четко определены связи между ее элементами, зависит производительность системы и ее информационная насыщенность, а значит - и время ее жизни.
Требования к базам данных
Итак, хорошо спроектированная база данных:
1. Удовлетворяет всем требованиям пользователей к содержимому базы данных. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
2. Гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
3. Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более “прозрачными” и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.
4. Удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности
начинают играть главную роль, сразу “высвечивая” все недочеты этапа проектирования.
Следующие пункты представляют основные шаги проектирования базы данных:
1. Определить информационные потребности базы данных.
2. Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности “деталь” характеристиками могут быть “название”, “цвет”, “вес” и т.п.) и сформировать их список.
3. Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).
4. Определить атрибуты, которые уникальным образом идентифицируют каждый объект.
5. Выработать правила, которые будут устанавливать и поддерживать целостность данных.
6. Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.
7. Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.