Разработка компьютерной программы "Учебная часть РПТ (Рузаевского политехнического техникума)"

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

• Содержание
• Введение
• 1. Теория проектирования базы данных
• 1.1 Основные понятия баз данных
• 1.2 Информационные, реляционные модели баз данных
• 1.3 Нормализация баз данных
• 1.4 Этапы проектирования баз данных
• 1.5 Базы данных и приложения
• 1.6 Таблицы баз данных
• 1.7 Ключи и индексы
• 2. Описание работы базы данных
• 2.1 Программа BDE Administrator
• 2.2 Работа с псевдонимами
• 2.3 Создание приложения BDE
• 3. Организация интерфейса с пользователем
• 3.1 Сервисные функции программы РПТ
• 3.2 Руководство пользователя
• 3.2.1 Запуск программы
• 3.2.2 Работа с программой
• 3.2.3 Завершение работы
• Заключение
• Список используемых источников
• Введение
• Современный научно-технический прогресс немыслим без широкого внедрения и использования вычислительной техники в производстве, управлении и научных исследованиях. Сегодня на основе ЭВМ разрабатываются и внедряются различные автоматизированные системы (управления, проектирования, технологической подготовки производства и др.). Успех во внедрении этих систем, их роль в интенсификации развития нашей страны во многом зависит от специалистов, знающих методику анализа и проектирования этих систем, возможности вычислительной техники и владеющих математическими методами, используемыми при постановке и решении задач. Естественно, что содержание разработок должно быть на уровне современных требований и обеспечивать решение поставленных задач на базе новых достижений в области вычислительной техники, информационного обеспечения, систем образования. Обязательной является разработка вопросов системного анализа объектов проектирования, оптимизации и выбора наилучших вариантов решений, а также разработка методов обеспечения надежности проектируемых систем.
• Применение ЭВМ в учебном процессе является естественным продолжением многолетнего процесса внедрения в обучение технических средств. Обладающие высоким быстродействием, большой памятью, способностью перерабатывать информацию, поступающую одновременно от многих пользователей, ЭВМ являются мощным средством повышения эффективности труда.
• Автоматизированные системы разработанные для конкретного учебного заведения являются одним из видов систем обработки информации.
• Государственное образовательное учреждение среднего профессионального образования “Рузаевский политехнический техникум” - единственное образовательное учреждение системы СПО в МР Рузаевка.
• Техникум сегодня это современное здание с оборудованными кабинетами, лабораториями, учебно-производственными мастерскими, учебно-вычислительным центром, тренажерным и актовым залами, библиотекой и читальным залом, буфетом.
• Образовательное учреждение ведет подготовку специалистов на очном отделении по образовательным программам:
• -151001 Технология машиностроения
• -150203 Сварочное производство
• -080110 Экономика и бухгалтерский учет
• -050504 Право и организация социального обеспечения
• -230103 Автоматизированные системы обработки информации и управления.
• Реализация профессиональных образовательных программ имеет достаточное информационное учебно-методическое обеспечение. Техникум оснащен современными компьютерами. Рузаевскому политехническому техникуму необходимо соответствующее программное обеспечение.
• С этой целью началась разработка компьютерной программы, обеспечивающая достижение заданной цели при оформлении документации очного отделения - «Учебная часть РПТ».
• «Учебная часть РПТ» - это программа работающая с базой данных, которая содержит полную информацию по работе очного отделения, а также программные средства поиска, добавления и обработки этой информации.
• Наполнение базы данных программы определяется индивидуально, в зависимости от информационных потребностей пользователя. При этом используется универсальная программная оболочка, а все пользователи взаимодействуют с системой посредством общего, единого для всех интерфейса.
• Целью моей работы является анализ существующих вопросов и проблем, касающихся автоматизации работы очного отделения, разработка концептуальной схемы базы данных, выбор технической базы и программного обеспечения для разработки программы и ее применение.
• 1. Теория проектирования базы данных
• 1.1 Основные понятия баз данных
• Часто для успешного функционирования различным организациям требуется развитая информационная система, реализующая автоматизированный процесс сбора, манипулирования и обработки данных.
• Современной формой информационных систем являются банки данных, имеющие в своем составе:
• вычислительную систему;
• систему управления базами данных (СУБД);
• одну или несколько баз данных (БД);
• набор прикладных программ (приложений БД).
• База данных (БД) обеспечивает хранение информации, а также удобный и быстрый доступ к данным. Она представляет собой совокупность данных различного характера, организованных по определенным правилам. Информация в БД должна быть:
• непротиворечивой;
• не избыточной;
• целостной.
• Система управления базой данных (СУБД) - это совокупность языковых и программных средств, предназначенных для создания, ведения и использования БД. По характеру применения СУБД разделяют на персональные и многопользовательские.
• Персональные СУБД обеспечивают возможность создания локальных БД, работающих на одном компьютере. К персональным СУБД относятся Paradox, dBase, FoxPro, Access и др.
• 1.2 Информационные, реляционные модели баз данных
• Типы информационных моделей
• Решать любую задачу, в том числе и информационную, можно различными способами. Для оценки вариантов проектируемых баз данных разрабатывают информационные модели. Разработка информационных моделей пока не имеет четких формализованных правил, поэтому эта задача, также как и процесс традиционного программирования, является «искусством» и зависит от квалификации разработчиков. Тем не менее существуют основные принципы создания информационных моделей для оценки оптимальности проектируемых баз данных.
• Информационная модель данных предусматривает три уровня описания системы: концептуальный, логический, физический, а соответственно -- три типа информационных моделей.
• Концептуальные модели данных
• Концептуальный уровень описания базы данных (концептуальная модель) представляет собой информационные объекты и их взаимосвязи без указания способов описания и хранения данных.
• В данном определении информационными объектами будем называть классы объектов, сведения о которых хранятся в таблицах базы данных. Как правило, в таблице базы данных содержатся сведения об объектах одного класса.
• Классом называют множество объектов, характеризующихся одинаковым набором признаков.
• Данные об информационных объектах одного класса могут находиться в одной или нескольких таблицах.
• Данные об информационных объектах разных классов должны находиться в разных таблицах.
• Конечной задачей разработки концептуальной модели является установление оптимального состава таблиц базы данных.
• Изложенные в предыдущих подразделах методы формирования состава таблиц базы данных на основе принципов нормализации в конечном итоге определяют концептуальную модель базы данных.
• Логические модели данных
• Логический уровень описания базы данных (логическая модель) отражает логические связи между таблицами.
• Физические модели данных
• Физический уровень описания реляционной базы данных (физические модели) характеризуют способы обработки и хранения информации. В теории и практике разработки баз данных и систем управления базами данных разделяют два подхода к построению физических моделей данных.
• Первый подход не связан с конкретной СУБД и предполагает описание физических свойств данных каждой таблицы -- физические модели таблиц базы данных.
• Второй подход к разработке физической модели связан с разработкой архитектуры, организации и хранения данных в конкретной СУБД -- физические модели хранения данных.
• Разработчик базы данных может не знать архитектуру прикладной программной системы, с помощью которой он создает свою информационную систему, но при этом он должен проработать физические модели для каждой таблицы.
• Физические модели таблиц базы данных. Физическая модель таблицы базы данных предполагает описание свойств каждого поля таблицы.
• Таким образом, разработка физической модели проекта таблицы базы данных сводится к описанию характеристик каждого поля. Приведем обязательные характеристики полей таблиц базы данных.
• Имя поля -- некоторый минимальный набор символов, предназначенный для поиска данных в таблице. В каждой прикладной программной системе для разработки баз данных существуют свои грамматические правила для формирования имен полей. В общем случае не допускается начинать имя поля с символа пробела, выбрать в качестве символов знаки препинания.
• Подпись поля идентифицируется с названием признака объекта, значения которого будут храниться в ячейках поля. Подпись поля будет находиться в заголовке таблицы. В современных СУБД не существует каких-либо ограничений на формирование подписи поля.
• Тип данных -- обозначение типа данных в соответствии с конкретной программной системой.
• Количество символов -- предполагаемое количество символов, которые будут храниться в ячейках поля.
• Точность -- число знаков после запятой в числовых полях.
• Ключ -- указание, что данное поле является ключевым. Данный состав свойств является минимально необходимым для описания данных, хранимых в таблице.
• Физические модели хранения данных. Физические модели хранения данных определяют методы размещения данных в памяти компьютера или на соответствующих носителях информации, а также способы хранения и доступа к этим данным. Исторически первыми системами хранения и доступа были файловые структуры и системы управления файлами (СУФ). Фактически файловые структуры хранения информации являлись и являются основой операционных систем. В системах управления базами данных использование файловых систем хранения информации оказалось не эффективным потому, что пользователю требовалась информация в виде отдельных данных, а не содержание всего файла. Поэтому в современных СУБД перешли от файловых структур к непосредственному размещению данных на внешних носителях -- устройствах внешней памяти. Однако механизмы управления, применяемые в файловых системах, во многом перешли и в новые системы организации данных во внешней памяти, называемые чаще страничными системами хранения информации.
• 1.3 Нормализация баз данных
• Одни и те же данные могут группироваться в таблицы (отношения) различными способами. Группировка атрибутов в отношениях должна быть рациональной, т. е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления. Устранение избыточности данных является одной из важнейших задач проектирования баз данных и обеспечивается нормализацией.
• Нормализация таблиц (отношений) -- это формальный аппарат ограничений на формирование таблиц (отношений), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных. Процесс нормализации заключается в разложении (декомпозиции) исходных отношений БД на более простые отношения. Каждая ступень этого процесса приводит схему отношений в последовательные нормальные формы. Для каждой ступени нормализации имеются наборы ограничений, которым должны удовлетворять отношения БД. Нормализация позволяет удалить из таблиц базы избыточную неключевую информацию.
• Процесс нормализации основан на понятии функциональной зависимости атрибутов: атрибут А зависит от атрибута В (В -» А), если в любой момент времени каждому значению атрибута В соответствует не более одного значения атрибута А.
• Зависимость, при которой каждый неключевой атрибут зависит от всего составного ключа и не зависит от его частей, называется полной функциональной зависимостью. Если атрибут А зависит от атрибута В, а атрибут В зависит от атрибута С (С -> В -> А), но обратная зависимость отсутствует, то зависимость С от А называется транзитивной.
• Общее понятие нормализации подразделяется на несколько «нормальных форм».
• Информационный объект (или сущность) находится в первой нормальной форме (1НФ), когда все его атрибуты имеют единственное значение. Если в каком-либо атрибуте есть повторяющиеся значения, объект (сущность) не находится в 1НФ, и упущен еще по крайней мере один информационный объект (еще одна сущность).
• Информационный объект находится во второй нормальной форме (2НФ), если он уже находится в первой нормальной форме, и каждый не идентифицирующий (описательный) атрибут зависит от всего уникального идентификатора информационного объекта. Если некий атрибут не зависит полностью от уникального идентификатора сущности, значит, он внесен ошибочно и должен быть удален. Нормализация в этом случае производится путем нахождения существующего информационного объекта, к которому данный атрибут относится, или созданием нового информационного объекта, в который атрибут должен быть помещен.
• Информационный объект (или сущность) находится в третьей нормальной форме (ЗНФ), если он уже находится во второй нормальной форме и ни один описательный атрибут не зависит от каких-либо других описательных атрибутов. Атрибуты, зависящие от других неидентифицирующих атрибутов, нормализуются путем перемещения зависимого атрибута и атрибута, от которого он зависит, в новый информационный объект.
• 1.4 Этапы проектирования баз данных
• Перед созданием базы данных разработчик должен определить, из каких таблиц должна состоять база данных, какие данные нужно поместить в каждую таблицу, как связать таблицы. Эти вопросы решаются на этапе проектирования базы данных.
• В результате проектирования должна быть определена логическая структура базы данных, то есть состав реляционных таблиц, их структура и межтабличные связи.
• Перед созданием базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, определить все необходимые источники информации для удовлетворения предполагаемых запросов пользователей и определить потребности в обработке данных.
• На основе такого описания на этапе проектирования базы данных определяются состав и структура данных предметной области, которые должны находиться в БД и обеспечивать выполнение необходимых запросов и задач пользователей. Структура данных предметной области может отображаться информационно-логической моделью. На основе этой модели легко создается реляционная база.
• Этапы проектирования и создания базы данных определяются следующей последовательностью:
• * построение информационно-логической модели данных предметной области;
• * определение логической структуры реляционной базы данных; * конструирование таблиц базы данных;
• * создание схемы данных;
• * ввод данных в таблицы (создание записей);
• * разработка необходимых форм, запросов, макросов, модулей, отчетов;
• * разработка пользовательского интерфейса.
• В процессе разработки модели данных необходимо выделить информационные объекты, соответствующие требованиям нормализации данных, и определить связи между ними. Эта модель позволяет создать реляционную базу данных без дублирования, в которой обеспечивается однократный ввод данных при первоначальной загрузке и корректировках, а также целостность данных при внесении изменений.
• При разработке модели данных могут использоваться два подхода. В первом подходе сначала определяются основные задачи, для решения которых строится база, выявляются потребности задач в данных и соответственно определяются состав и структура информационных объектов. При втором подходе сразу устанавливаются типовые объекты предметной области. Наиболее рационально сочетание обоих подходов. Это связано с тем, что на начальном этапе, как правило, нет исчерпывающих сведений обо всех задачах. Использование такой технологии тем более оправдано, что гибкие средства создания реляционных баз данных позволяют на любом этапе разработки внести изменения в базу данных и модифицировать ее структуру без ущерба для введенных ранее данных.
• Процесс выделения информационных объектов предметной области, отвечающих требованиям нормализации, может производиться на основе интуитивного или формального подхода.
• При интуитивном подходе легко могут быть выявлены информационные объекты, соответствующие реальным объектам. Однако получаемая при этом информационно-логическая модель, как правило, требует дальнейших преобразований, в частности преобразования многозначных связей между объектами. При таком подходе возможны существенные ошибки, если отсутствует достаточный опыт. Последующая проверка выполнения требований нормализации обычно показывает необходимость уточнения информационных объектов.
• Рассмотрим формальные правила, которые могут быть использованы для выделения информационных объектов:
• на основе описания предметной области выявить документы и их атрибуты, подлежащие хранению в базе данных;
• определить функциональные зависимости между атрибутами;
• выбрать все зависимые атрибуты и указать для каждого все его ключевые атрибуты, т. е. те, от которых он зависит;
• сгруппировать атрибуты, одинаково зависимые от ключевых атрибутов. Полученные группы зависимых атрибутов вместе с их ключевыми атрибутами образуют информационные объединение;
• При определении логической структуры реляционной базы данных на основе модели каждый информационный объект адекватно отображается реляционной таблицей, а связи между таблицами соответствуют связям между информационными объектами.
• В процессе создания сначала конструируются таблицы базы данных, соответствующие информационным объектам построенной модели данных. Далее может создаваться схема данных, в которой фиксируются существующие логические связи между таблицами.
• Эти связи соответствуют связям информационных объектов. В схеме данных могут быть заданы параметры поддержания целостности базы данных, если модель данных была разработана в соответствии с требованиями нормализации. Целостность данных означает, что в БД установлены и корректно поддерживаются взаимосвязи между записями разных таблиц при загрузке, добавлении и удалении записей в связанных таблицах, а также при изменении значений ключевых полей.
• После формирования схемы данных осуществляется ввод непротиворечивых данных из документов предметной области.
• На основе созданной базы данных формируются необходимые запросы, формы, модули, отчеты, производящие требуемую обработку данных базы и их представление с помощью встроенных средств и инструментов базы данных создается пользовательский интерфейс, позволяющий управлять процессами ввода, хранения, обработки, обновления и представления информации базы данных.
• 1.5 Базы данных и приложения
• В зависимости от взаимного расположения приложения и БД можно выделить:
• - локальные БД;
• - удаленные БД.
• Для выполнения операций с локальными БД разрабатываются и используются так называемые локальные приложения, а для операций с удаленными БД -- клиент-серверные приложения.
• Расположение БД в значительной степени влияет на разработку приложения, обрабатывающего содержащиеся в этой базе данные.
• Так, различают следующие виды приложений:
• приложения, использующие локальные базы данных, называют одноуровневыми (однозвенными) приложениями, поскольку приложение и базы
• данных образуют единую файловую систему;
• приложения, использующие удаленные базы данных, разделяют на двухуровневые (двухзвенные) и многоуровневые (многозвенные). Двухуровневые приложения содержат клиентскую и серверную части;
• многоуровневые (обычно трехуровневые) приложения кроме клиентской и серверной частей имеют дополнительные части. К примеру, в трехуровневых приложениях имеются клиентская часть, сервер приложений и сервер базы данных.
• 1.6 Таблицы баз данных
• Таблицы, образующие БД, находятся в каталоге на жестком диске.
• Таблицы хранятся в файлах и похожи на отдельные документы или электронные таблицы, например, табличного процессора Microsoft Excel, их можно перемещать и копировать обычным способом, скажем, с помощью Проводника Windows. Однако в отличие от документов, таблицы БД поддерживают многопользовательский режим доступа, это означает, что их могут одновременно использовать несколько приложений.
• Для одной таблицы создается несколько файлов, содержащих данные, индексы, ключи и т. п. Главным из них является файл с данными, его имя совпадает с именем таблицы, которое задается при ее создании. В некотором смысле понятия таблицы и ее главного файла являются синонимами, при выборе таблицы выбирается именно ее главный файл: для таблицы dBase это файл с расширением dbf, а для таблицы Paradox -- с расширением
• db- Имена остальных файлов таблицы назначаются автоматически -- все файлы имеют одинаковые имена, совпадающие с именами таблиц, и разные расширения, указывающие на содержимое соответствующего файла. Каждая таблица БД состоит из строк и столбцов и предназначена для хранения данных об однотипных объектах информационной системы. Строка таблицы называется записью, столбец таблицы-- полем:
• Рисунок 1 - Схема таблицы базы данных
• Каждое поле должно иметь уникальное в пределах таблицы имя.
• Поле содержит данные одного из допустимых типов, например, строкового, целочисленного или типа "дата". При вводе значения в поле таблицы автоматически производится проверка соответствия типа значения и типа поля.
• Если они не совпадают, а преобразование типа значения невозможно, генерируется исключение.
• Особенности организации таблиц зависят от конкретной СУБД, используемой для создания и ведения БД.
• Основу таблицы составляет описание ее полей (каждая таблица должна иметь хотя бы одно поле). Понятие структуры таблицы является более широким и включает:
• - описание полей;
• - ключ;
• - индексы;
• - ограничения на значения полей;
• - ограничения ссылочной целостности между таблицами;
• - пароли.
• Иногда ограничения на значения полей, ограничения ссылочной целостности между таблицами, а также права доступа называют одним общим термином "ограничения".
• Отметим, что отдельные элементы структуры зависят от формата таблиц, например, для таблиц dBase нельзя задать ограничения ссылочной целостности (т. к. у них нет ключей). Все элементы структуры задаются на физическом уровне (уровне таблицы) и действуют для всех программ, выполняющих операции с БД, включая средства разработки и ведения БД (например, программу Database Desktop). Многие из этих элементов можно также
• реализовать в приложении программно, однако в этом случае они действуют только в пределах своего приложения.
• С таблицей в целом можно выполнять следующие операции:
• - создание (определение структуры);
• - изменение структуры (реструктуризация);
• - переименование;
• - удаление.
• При создании таблицы задаются структура и имя таблицы. При сохранении на диске создаются все необходимые файлы, относящиеся к таблице. Их имена совпадают с именем таблицы. При изменении структуры таблицы в ней могут измениться имена и
• характеристики полей, состав и наименования ключа и индексов, ограничения. Однако имена таблицы и ее файлов остаются прежними.
• При переименовании таблица получает новое имя, в результате чего новое имя также получают все ее файлы. Для этого используются соответствующие программы (утилиты), предназначенные для работы с таблицами БД, например, Database Desktop.
• Таблицу нельзя переименовать, просто изменив названия всех ее файлов, например, с помощью Проводника Windows.
• При удалении таблицы с диска удаляются все ее файлы. В отличие от переименования, удаление таблицы можно выполнить посредством любой программы (в том числе и с помощью Проводника Windows).
• 1.7 Ключи и индексы
• Ключ представляет собой комбинацию полей, данные в которых однозначно определяют каждую запись в таблице. Простой ключ состоит из одного поля, а составной (сложный) -- из нескольких полей. Поля, по которым построен ключ, называют ключевыми. В таблице может быть определен только один ключ.
• Ключ обеспечивает:
• однозначную идентификацию записей таблицы;
• ускорение выполнения запросов к БД;
• установление связи между отдельными таблицами БД;
• использование ограничений ссылочной целостности.
• Ключ также называют первичным ключом или первичным (главным) индексом.
• Информация о ключе может храниться в отдельном файле или совместно с данными таблицы. Например, в БД Paradox для этой цели используется отдельный файл (ключевой файл или файл главного индекса) с расширением рх. В БД Access вся информация содержится в одном общем файле с расширением mdb. Значения ключа располагаются в определенном порядке.
• Для каждого значения ключа имеется уникальная ссылка, указывающая на расположение соответствующей записи в таблице (в главном ее файле). Поэтому при поиске записи выполняется не последовательный просмотр всей таблицы, а прямой доступ к записи на основании упорядоченных значений ключа.
• Таблицы различных форматов имеют свои особенности построения ключей.
• Вместе с тем существуют и общие правила:
• ключ должен быть уникальным. У составного ключа значения отдельных полей (но не всех одновременно) могут повторяться;
• ключ должен быть достаточным и не избыточным, т. е. не содержать поля, которые можно удалить без нарушения уникальности ключа;
• в состав ключа не могут входить поля некоторых типов, например, графическое поле или поле комментария.
• Выбор ключевых полей не всегда является простой и очевидной задачей, особенно для таблиц с большим количеством полей. Нежелательно выбирать в качестве ключевых поля, содержащие фамилии людей, в таблице сотрудников организации или названия товаров в таблице данных склада.
• В этом случае высока вероятность существования двух и более однофамильцев, а также товаров с одинаковыми названиями, которые различаются, к примеру, цветом (значение другого поля). Для указанных таблиц можно использовать, например, поде кода сотрудника и поле артикула товара. При этом предполагается, что указанные значения являются уникальными.
• Удобным вариантом создания ключа является использование для него поля соответствующего типа, которое автоматически обеспечивает поддержку уникальности значений. Например, для таблиц Paradox таким является поле автоинкрементного типа, достоинством которого является небольшой размер. В то же время в таблицах dBase и InterBase поле подобного типа отсутствует, и программист должен обеспечивать уникальность значений ключа самостоятельно, например, используя специальные генераторы автоинкрементных полей.
• Индекс, как и ключ, строится по полям таблицы, однако он может допускать повторение значений составляющих его полей -- в этом и состоит его основное отличие от ключа. Поля, по которым построен индекс, называют индексными. Простой индекс состоит из одного поля, а составной (сложный) -- из нескольких полей.
• Индексы при их создании именуются. Как и в случае с ключом, в зависимости от СУБД индексы могут храниться в отдельных файлах или совместно с данными. Создание индекса называют индексированием таблицы.
• Использование индекса обеспечивает:
• увеличение скорости доступа к данным (поиска);
• сортировку записей;
• установление связи между отдельными таблицами БД;
• использование ограничений ссылочной целостности.
• В двух последних случаях индекс применяется совместно с ключом второй таблицы.
• Сортировка представляет собой упорядочивание записей по полю или группе полей в порядке возрастания или убывания их значений. Можно сказать, что индекс служит для сортировки таблиц по индексным полям. В частности, в C++ Builder записи набора Table можно сортировать только по индексным полям. Набор данных Query позволяет выполнить средствами SQL сортировку по любым полям, однако и в этом случае для индексированных полей упорядочивание записей выполняется быстрее.
• Для одной таблицы можно создать несколько индексов. В каждый момент времени один из них можно сделать текущим, т. е. активным. Даже при существовании нескольких индексов таблица может не иметь текущего индекса (текущий индекс важен, например, при выполнении поиска и сортировки записей набора данных Table).
• Ключевые поля обычно индексируются автоматически. В таблицах Paradox ключ также является главным (первичным) индексом, который не именуется. Для таблиц dBase ключ не создается, и его роль выполняет один из индексов.
• Таким образом, использование ключей и индексов позволяет:
• однозначно идентифицировать записи;
• избегать дублирования значений в ключевых полях;
• выполнять сортировку таблиц;
• ускорять операции поиска в таблицах;
• устанавливать связи между отдельными таблицами БД;
• использовать ограничения ссылочной целостности.
• Одной из основных задач БД является обеспечение быстрого доступа к данным (поиска данных). Время доступа к данным в значительной степени зависит от используемых для поиска данных методов и способов.
• Связи между таблицами В частном случае БД может состоять из одной таблицы. Однако обычно реляционная БД состоит из набора взаимосвязанных таблиц. Организация связи (отношений) между таблицами называется связыванием или соединением таблиц.
• Связи между таблицами можно устанавливать как при создании БД, так и при выполнении приложения, используя средства, предоставляемые СУБД.
• Связывать можно две или несколько таблиц. В реляционной БД, кроме связанных таблиц, могут быть и отдельные таблицы, не соединенные ни с одной другой таблицей. Это не меняет сути реляционной БД, которая содержит единую информацию о некоторой системе, связанную не в буквальном (связь между таблицами), а в функциональном смысле -- вся информация относится к одной системе.
• Для связывания таблиц используются поля связи (иногда применяется термин "совпадающие поля"). Поля связи обязательно должны быть индексированными. В подчиненной таблице для связи с главной таблицей задается индекс, который называется внешним ключом. Состав полей этого индекса должен полностью или частично совпадать с составом полей индекса главной таблицы.
• Особенности использования индексов зависят от формата связываемых таблиц. Так, для таблиц dBase индексы строятся по одному полю и нет деления на ключ (главный или первичный индекс) и индексы. Для организации связи в главной и подчиненной таблицах выбираются индексы, составленные по полям совпадающего типа, например, целочисленного.
• Для таблиц Paradox в качестве полей связи главной таблицы должны использоваться поля ключа, а для подчиненной таблицы -- поля индекса. Кроме того, в подчиненной таблице обязательно должен быть определен ключ.
• Связь между таблицами определяет отношение подчиненности, при котором одна таблица является главной (родительской, или мастером -- Master), а вторая -- подчиненной (дочерней, или детальной -- Detail). Саму связь (отношение) называют связь "главный-подчиненный", "родительский- дочерний" или "мастер-детальный". Существуют следующие виды связи:
• отношение "один-к-одному";
• отношение "один-ко-многим";
• отношение "много-к-одному";
• отношение "много-ко-многим".
• Отношение "один-к-одному" означает, что одной записи в главной таблице соответствует одна запись в подчиненной таблице. При этом возможны два варианта:
• для каждой записи главной таблицы есть запись в подчиненной таблице;
• в подчиненной таблице может не быть записей, соответствующих записям главной таблицы.
• Отношение "один-к-одному" обычно используется при разбиении таблицы с большим числом полей на несколько таблиц. В этом случае в первой таблице остаются поля с наиболее важной и часто используемой информацией, а остальные поля переносятся в другую (другие) таблицу.
• Отношение "один-ко-многим" означает, что одной записи главной таблицы в подчиненной таблице может соответствовать несколько записей, в том числе ни одной записи. Этот вид отношения встречается наиболее часто. После установления связи между таблицами при перемещении на какую-либо запись в главной таблице, в подчиненной таблице автоматически становятся доступными записи, у которых значение поля связи равно значению поля связи текущей записи главной таблицы. Такой отбор записей подчиненной таблицы является своего рода фильтрацией.
• Отношение "много-к-одному" отличается от отношения "один-ко-многим" только направлением. Если на отношение "один-ко-многим" посмотреть со стороны подчиненной таблицы, а не главной, то оно превращается в отношение "много-к-одному".
• Отношение "много-ко-многим" имеет место, когда одной записи главной таблицы может соответствовать несколько записей подчиненной таблицы, и одновременно одной записи подчиненной таблицы -- несколько записей главной таблицы.
• На практике отношение "много-ко-многим" используется достаточно редко.
• Причинами являются сложность организации связи между таблицами и взаимодействия между их записями. Кроме того, многие СУБД, в том числе Paradox, не поддерживают организацию ссылочной целостности для подобного отношения. Отметим также, что для отношения "много-ко-многим" понятия главной и подчиненной таблицы не имеют смысла.
• Среди рассмотренных отношений наиболее общим является отношение "один-ко-многим". Другие виды отношений можно рассматривать как его варианты -- отношение «один-к-одному" представляет собой частный случай этого отношения, а отношение "много-к-одному" является его "переворотом". Отношение "много-ко-многим" можно свести к отношению "один-ко-многим", соответствующим образом преобразовав и разделив таблицы.
• В дальнейшем предполагается, что таблицы связаны именно отношением "один-ко-многим".
• Работа со связанными таблицами имеет следующие особенности:
• при изменении (редактировании) поля связи может нарушиться связь между записями двух таблиц. Поэтому при редактировании поля связи главной таблицы нужно соответственно изменять и значения поля связи всех подчиненных таблиц;
• при удалении записи главной таблицы нужно удалять и соответствующие ей записи в подчиненной таблице (каскадное удаление);
• при добавлении записи в подчиненную таблицу значение ее поля связи должно быть установлено равным значению поля связи главной таблицы.
• Ограничения по установке, изменению полей связи и каскадному удалению записей могут быть наложены на таблицы при их создании. Эти ограничения наряду с другими элементами, например, описаниями полей и индексов, входят в структуру таблицы и действуют для всех приложений, которые выполняют операции с БД. Указанные ограничения можно задать при создании или реструктуризации таблицы, например, в среде программы Database Desktop, которая позволяет устанавливать связи между таблицами при их создании.
• Ограничения, связанные с установкой, изменением значений полей связи и каскадным удалением записей, могут и не входить в структуру таблицы (таблиц), а реализовываться программным способом. В этом случае программист должен обеспечить:
• организацию связи между таблицами;
• установку значения поля связи подчиненной таблицы (это может выполняться автоматически);
• контроль (запрет) редактирования полей связи;
• организацию (запрет) каскадного удаления записей.
• 2. Описание работы базы данных
• 2.1 Программа BDE Administrator
• Программа BDE Administrator представляет собой инструмент администрирования процессора баз данных BDE (далее Администратор BDE, или Администратор). Для вызова Администратора BDE запускается файл bdeadmin.exe, находящийся в одном каталоге с процессором баз данных. Внесенные изменения сохраняются по окончании работы с Администратором в файле конфигурации idapi32.cfg. Программу также можно вызвать через главное меню Windows выбором пункта Program\Borland C++ Builder 6\BDE Administrator.
• Администратор BDE позволяет настраивать параметры БД и операционной системы. Основные параметры: - параметры псевдонима БД:
• * название;
• * тип;
• * путь.
• - параметры драйвера:
• * тип;
• * язык.
• - системные установки:
• * установки по умолчанию;
• * форматы даты, времени и числовые форматы.
• Для настройки требуемого параметра в левой части окна Администратора BDE нужно выбрать нужный объект, после чего в правой части окна открывается доступ к списку параметров этого объекта. При редактировании выбранного в панели инструментов объекта становятся доступными кнопки отмены/подтверждения сделанных изменений.
• Отменить или подтвердить изменения можно также командами Cancel и Apply главного или контекстного меню.

2.2 Работа с псевдонимами

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

Для создания псевдонима базы данных перед вызовом пункта меню Object\New Администратора BDE нужно выбрать вкладку Database в левой части окна, в противном случае команда New меню будет недоступна. После задания этой команды появляется диалоговое окно New Database Alias (Новый псевдоним БД) представленное на рисунке 2.1, в котором нужно выбрать тип драйвера. Для локальных таблиц Paradox и dBase выбирается тип standard.

Рисунок 2.1 - Новый псевдоним БД

После нажатия кнопки ОК создается псевдоним и его данные отображаются в окне Администратора BDE представленном на рисунке __. Новый псевдоним автоматически получает имя standard1 и параметры по умолчанию. Можно переименовать. Псевдоним, выполнив команду Rename контекстного меню псевдонима.

Псевдоним для работы с локальными БД имеет три параметра:

- default driver -- указывает формат таблиц БД (по умолчанию имеет значение paradox). Кроме того, можно установить значения dBase или asciidrv для текстовых файлов, разбитых на колонки;

- enable bcd -- указывает на необходимость перевода чисел в формат BCD, что позволяет более точно выполнять вычисления, но уменьшает скорость их выполнения. По умолчанию имеет значение false и, соответственно, формат BCD не используется;

- path -- указывает расположение (каталог) БД. После создания псевдонима путь не определен, и мы устанавливаем его самостоятельно С:\Uch1\db.

Рисунок 2.2 - Установка параметров псевдонима

Для работы с таблицами БД при проектировании приложения удобно использовать программу Database Desktop, которая позволяет:

создавать таблицы;

изменять структуры;

редактировать записи.

Кроме того, с помощью Database Desktop можно выполнять и другие действия над БД (создание, редактирование, выполнение визуальных и SQL- запросов, операции с псевдонимами).

Для этого чтобы открыть программу выбираем Пуск/Все программы/ Borland C++ Builder/ Database Desktop.

Процесс создания новой таблицы начинается с вызова команды File\New\Table (Файл\Новая\Таблица) и происходит в интерактивном режиме. При этом необходимо:

выбрать формат (тип) таблицы;

задать структуру таблицы.

В начале создания новой таблицы в окне Create Table (Создание таблицы) выбирается ее формат. По умолчанию предлагается формат таблицы Paradox версии 7, который я использовала.

После выбора формата таблицы появляется окно определения структуры таблицы, в котором выполняются следующие действия:

описание полей;

задание ключа;

задание индексов;

определение ограничений на значения полей;

определение условий (ограничений) ссылочной целостности;

задание паролей;

задание языкового драйвера;

задание таблицы для выбора значений.

В этом списке обязательным является только первое действие, т. е. каждая таблица должна иметь хотя бы одно поле. Остальные действия выполняются при необходимости. Часть действий, таких как задание ключа и паролей, производится только для таблиц определенных форматов, например, для таблиц Paradox.

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

Рисунок 2.3 - Создание таблицы Paradox

Центральной частью окна определения структуры таблицы является список Field roster (Список полей), в котором указываются поля таблицы. Для каждого поля задаются:

имя поля -- в столбце Field Name;

тип поля -- в столбце Туре;

размер поля -- в столбце Size.

Имя поля вводится по правилам, установленным для выбранного формата таблиц.

Добавление к списку полей новой строки выполняется переводом курсора вниз на несуществующую строку, в результате чего эта строка появляется в конце списка. Вставка новой строки между существующими строками с уже описанными полями выполняется нажатием клавиши <Insert>. Новая строка вставляется перед строкой, в которой расположен курсор. Для удаления строки необходимо установить курсор на эту строку и нажать комбинацию клавиш <Ctrl>+<Delete>.

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

Рисунок 2.4 - Выбор типа поля таблицы Paradox

Для выполнения операций, связанных с заданием ограничений на значения полей, нужно выбрать пункт Validity Checks (Проверка значений) комбинированного списка Table properties, при этом ниже списка появляются флажок Required Field (Обязательное поле), поля редактирования Minimum Value (Минимальное значение), Maximum Value (Максимальное значение), Default Value (значение по умолчанию), Picture (Маска ввода) и кнопка Assist (Помощь). Флажок и поля редактирования отображают установки для поля таблицы, которое выбрано в списке (курсор находится в строке этого поля).

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

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

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

Рисунок 2.5 - Задание параметров таблицы

Для выполнения операций, связанных с заданием ссылочной целостности, необходимо выбрать пункт Referential Integrity комбинированного списка Table properties. При этом, как и в случае задания индексов, появляются кнопки Define, Modify, Erase и список, в котором выводятся имена созданных условий ссылочной целостности.

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

полями связи подчиненной таблицы;

именем главной таблицы;

полями связи главной таблицы;

параметрами.

Можно создать, изменить или удалить условие ссылочной целостности. Для задания условия ссылочной целостности нужно нажать кнопку Define, после чего появляется окно Referential Integrity.

Поле связи следует выбрать в списке Fields и нажатием кнопки со стрелкой вправо перевести его в список Child fields (Дочерние поля). Если полей связи несколько, то эти действия выполняются для каждого из них. Кнопка со стрелкой влево удаляет выбранное поле из списка дочерних полей.

Рисунок 2.6 - Задание новой ссылочной целостности

Главная таблица указывается в списке Table, имена таблиц выбираются в рабочем каталоге программы Database Desktop (каталог, определенный как Working Directory). После выбора таблицы и нажатия кнопки со стрелкой влево (рядом со списком таблиц) в поле Parent's key автоматически заносятся ключевые поля главной таблицы.

2.3 Создание приложения BDE

Запустите C++ Builder. Далее перейдите на закладку Standard на панели в верхней части программы и вынесите на форму приложения компонент MainMenu -- главное меню для будущего приложения. Затем щелкнула по добавленному на форму элементу (MainMenu) дважды левой кнопкой мышки. В открывшемся окне с заголовком Form1->MainMenu1 сформировала основные каскадные меню:

1. Студенты

1.1. Список

-полный

-по группам

1.2 Личная карточка

1.3 Успеваемость

1.4 Оценки по ведомости

2. Ведомости

2.1 Экзаменационная

2.2 Зачетная

2.3 Сводная

3. Преподаватели

3.1 Ввод часов преподавателей

3.2 Ведомость учета часов

3.3 Отчет по часам

4. Справочники

5. Год

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

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

Для работы с компонентами меню во время разработки используется специализированный Редактор меню представленный на рисунке ____. Он открывается при щелчке на кнопке свойства items компонента меню в Инспекторе объектов или при двойном щелчке на компоненте. Он обеспечивает отображение всех элементов меню, представленных в свойстве items.

Редактор меню активно взаимодействует с Инспектором объектов. Для каждого выбранного в Редакторе элемента в Инспекторе объектов появляются значения его свойств.

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

Рисунок 2.7 - Формируем элементы главного меню в окне Form1.

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

Вид формы приложения на этапе проектирования показан на рисунке ___, где в форме размещены компоненты Table1, DataSource1, DBGrid1 и DBNavigator1.

Компонент Table1 обеспечивает взаимодействие с таблицей БД. Для связи с требуемой таблицей нужно установить соответствующие значения свойству DataBaseName, указывающему путь к БД или алиас, и свойству TableName, указывающему имя таблицы. После задания таблицы для открытия набора данных свойству Active должно быть установлено значение true.

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

Компонент DataSource1 является промежуточным звеном между компонентом Table1, соединенным с реальной таблицей БД, и визуальными компонентами DBGrid1 и DBNavigator1, с помощью которых пользователь взаимодействует с этой таблицей. На компонент Table1 с которым связан компонент DataSource1, указывает свойство DataSet последнего.

Рисунок 2.8 - Форма приложения для работы с БД

Компонент DBGrid1 отображает содержимое таблицы БД в виде сетки, в которой столбцы соответствуют полям, а строки -- записям таблицы. По умолчанию пользователь может просматривать и редактировать данные. Компонент DBNavigator позволяет пользователю перемещаться по таблице, редактировать, вставлять и удалять записи. Компоненты DBGrid1 и DBNavigator1 связываются со своим источником данных -- компонентом DataSource1 -- через свойства DataSource.

Схема взаимосвязи компонентов приложения и таблицы БД и используемые при этом свойства компонентов показаны на рисунке 2.9.

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

Рисунок 2.9 - Схема взаимосвязи компонентов приложения и таблицы БД

Доступ к остальным таблицам организуется аналогичным образом. В основном окне программы (Список студентов) находятся:

- Успеваемость студента;

- Успеваемость за семестр;

- Распечатать личную карточку.

При нажатии на кнопку успеваемость за семестр данные фильтруются по группе, а затем делается проверка оценок (отлично, хорошо, удовлетворительно, неудовлетворительно) с занесением в соответствующую таблицу [Приложение А].

if(Form3->ShowModal()!=mrOk) return;

Variant A_,B_,T_,D_,V_;

char gg[6],sp[3];

int kurs, sem, i,oc5,oc4,oc3,oc2,kol[6],t=0;

String oo,pre2;

try{

A_ = CreateOleObject("Word.Application");

B_=A_.OlePropertyGet("WordBasic");

B_.OleProcedure("FileNew", (ExtractFilePath(ParamStr(0))+"usp.dot").c_str());

D_=A_.OlePropertyGet("ActiveDocument");

V_=D_.OlePropertyGet("Variables");

strcpy(gg,Form3->DBLookupComboBox1->Text.c_str());

if (gg[1]=='-') {sp[0]=gg[0];sp[1]=0; kurs=gg[2]-48;}

else {sp[0]=gg[0];sp[1]=gg[1];sp[2]=0; kurs=gg[3]-48;}

sem=(kurs-1)*2+(Form3->RadioButton1->Checked?1:2);

V_.OleProcedure("Add", "Nom_kurs", kurs);

V_.OleProcedure("Add", "Nom_gr", (Form3->DBLookupComboBox1->Text) .c_str());

V_.OleProcedure("Add", "Sem", Form3->RadioButton1->Checked?1:2);

V_.OleProcedure("Add", "Uch_god", ((String)uch_god+"-"+(String)(uch_god+1)).c_str());

D_.OlePropertyGet("Fields").OleProcedure("Update");

B_.OleProcedure("AppShow");

//student->Filter="Spec='"+(String)sp+"' AND Nom_kurs="+(String)kurs+" AND Nom_gr="+(String)gr;

student->Filter="Gruppa='"+Form3->DBLookupComboBox1->Text+"'";

student->Filtered=true;

Label23->Caption=Form3->DBLookupComboBox1->Text;

ocenka->Active=false;

ocenkafio_stud->Visible=false;

ocenkafio_stud->FieldKind=fkCalculated;

ocenkan_predmet->FieldKind=fkLookup;

ocenkan_predmet->Visible=true;

ocenka->IndexName="Nom_zach";

ocenka->MasterFields="";

ocenka->MasterSource=dstudent;

ocenka->MasterFields="nom_zach";

ocenka->Active=true;

student->First();

char sss[20];

kol[2]=0;

kol[3]=0;

kol[4]=0;

kol[5]=0;

while(!student->Eof)

{ocenka->First();

char oc[]="Oc0";

oc[2]=sem+48;

oc5=0;oc4=0;oc3=0;oc2=0;t=0;

pre2="";

while(!ocenka->Eof)

{if (ocenka->FieldByName(oc)->IsNull) {ocenka->Next();continue;}

oo=ocenka->FieldByName(oc)->AsString;

if (oo[1]=='2'||oo[1]=='н') {oc2++;pre2=pre2+ocenka->FieldByName("n_predmet")->AsString+" ,";}

if (oo[1]=='3') oc3++;

if (oo[1]=='4') oc4++;

if (oo[1]=='5') oc5++;

ocenka->Next();}

if (oc2>0) {t=2;T_=D_.OlePropertyGet("Tables").OleFunction("Item",5);}

else if (oc3>0) {t=3;T_=D_.OlePropertyGet("Tables").OleFunction("Item",4);}

...