Тезисы лекционных занятий
по дисциплине «Базы данных и их приложения»
для специальности «050601 Математика»
Лекция №1
Тема: Введение в БД
Взаимосвязь БД, ИС и СУБД. Создание и модификация таблиц через Table Designer. Работа с БД. Связывание таблиц, ключевые атрибуты
Основные вопросы: Из истории развития теории баз данных. Приложения в области баз данных Этапы создания и способы модификации таблиц. Типы полей Копирование и сортировка таблиц Индексирование
Успешная практическая деятельность человека все чаще в большей степени зависит от эффективной организации обмена информацией. Информация все чаще рассматривается как жизненно важный ресурс, который должен быть организован так, чтобы им можно было легко пользоваться. Сегодня все большее число организаций приходит к пониманию того, что без наличия своевременной и объективной информации о состоянии рынка, прогнозирования его перспектив, постоянной оценки эффективности функционирования собственных структур и анализа взаимоотношений с бизнес-партнерами и конкурентами их дальнейшее развитие становится практически невозможным. Поэтому не удивительно то внимание, которое сегодня уделяется средствам реализации и концепциям проектирования автоматизированных информационных систем, ориентированных на аналитическую обработку данных. И в первую очередь, это касается систем управления базами данных. Формирование корпоративных информационных систем, которые можно рассматривать как информационную систему с усложненной многофункциональной структурой, требует профессионального подхода к проектированию данных, которыми манипулируют подобные системы.
Определение по К. Дейту: “Компьютеризированная система хранения записей. База данных – подобие электронной картотеки, т.е. хранилище для некоторого набора занесенных в компьютер набора данных”. Создание базы данных, таблиц, индексов. В Visual FoxPro под базой данных понимают совокупность таблиц. Создание таблицы осуществляется командой
CREATE TABLE имя таблицы
Длина имени таблицы может быть от 1-го до 128 символов. Сначала задается структура таблицы, затем происходит заполнение пустой структуры содержанием, занесение записей.
Для задания структуры таблицы необходимо определить наименования полей, их типы, значности каждого из полей. В имени поля рекомендуется сохранять мнемонический смысл информации, содержащейся в качестве значений поля и первым символом выбирать признак типа поля. Типы полей, их названия, допустимые границы значений полей того или иного типа можно представить таблицей.
Таблица 3 Типы полей Visual FoxPro
тип поля
допустимый диапазон
назначение
Character
1-254 символов
для символьной информации
Numeric
не более 20 цифр, не более 19 десятичных знаков
для числовой операции
Date
6-8 формат yyyy/mm/dd
для дат
Logical
.F. – лог. ложь и истина .T.
для логических значений
Memo
переменная длина
для символьных полей, которые лишь иногда заполняются
очень большие символьные поля, длину которых заранее не предсказуема
текстовые файлы с резюме, архивами версий программ
General
переменная длина
для хранения графических изображений и отличается от мемо поля тем, что предназначено для ссылок на связанные объекты
Currency
макс.значение немного превышает 922 триллиона $
для денежных сумм
Float (double float)
для Double Float приближенное макс.значение до 8.99Е+307
Float то же, что и Numeric
Double Float вещественное число с двойной точностью в сжатом формате
DateTime
формат HHMMSS
сжатый формат хранения времени
На практике при работе с данными типа DATE могут понадобиться следующие SET – команды:
SET DATE TO [BRIT, AMER, JAPAN] && настройка формата представления даты
SET CENTURY ON/OFF && вывод (скрытие) века в формате даты
SET MARK TO [“-”, “/”, “.”] && настройка формата разделительного символа
В дальнейшем для изменения структуры таблицы применяется команда:
USE имя таблицы && открытие таблицы
MODIFY STRUCTURE && изменение структуры
При заполнении структуры реальными записями можно применять следующие команды:
APPEND [BLANK] && добавление (пустой) записи
BROWSE && полноэкранное редактирование
DELETE && удаление (пометка на удаление) записи
PACK && физическое удаление всех помеченных на удаление записей
Связывание таблиц, как правило, организуется через индексные поля. Индексирование таблиц позволяет пользователям просматривать и выбирать данные из таблицы в определенном порядке, предоставляет ускоренный доступ к данным. Различают следующие виды индексов:
автономные (.idx)
составные (.cdx)
неструктурные;
структурные
Классификация индексных файлов по принципу формирования индексов рассматривает разделение на автономные и составные индексные файлы. VFoxPro работает в основном с составными структурными индексными файлами. Далее рассматриваемая классификация структурного индекса предполагает разделение индекса на следующие типы по принципу функционирования индексов:
regular (регулярный)
unique (уникальный)
candidate (потенциальный)
primary (первичный)
Регулярный тип сохраняет в индексе значения, сгенерированные индексным выражением для каждой записи таблицы. Если несколько записей имеют одно и то же значение, то это значение заносится в индекс несколько раз, но с различными значениями указателей для каждой записи.
Уникальный тип допускает существование уникальных значений индексного выражения. Если несколько записей генерируют одно и то же значение индексного выражения, в индексе сохранится значение только первой встретившейся записи.
Потенциальный тип предполагает наличие уникальных значений индексного выражения. При наличии повторяющихся значений в индексе этот тип работает как регулярный, то есть повторяющиеся значения заносятся в индекс с разными значениями указателей, но при этом выдается предупреждение о нарушаемой уникальности индекса и предложение проверки данных таблицы на соответствие требованиям такой индексации.
Первичный тип могут иметь только таблицы, включенные в контейнер базы данных. На базе первичных ключей часто формируются отношения между несколькими таблицами.
В качестве индексного выражения может выступать любая комбинация полей. Для построения сложного индексного выражения используется кнопка Expression... на вкладке Indexes диалогового окна Table Designer.
^ Создание базы данных. Далее рассмотрим команду создания и модификации контейнера для хранения таблиц.
CREATE DATABASE имя базы данных (.dbc) && создание
MODIFY DATABASE && изменение
SET DATABASE TO && переход к другой базе данных
Лекция №2Тема: Архитектура СУБД.
Уровни представления данных. Базовый язык и подъязыки представления данных Клиент-серверные технологии.^ Основные вопросы: Модель 3-х уровневой архитектуры. Категории пользователей БД Схемы клиент-серверной архитектуры. Распределенная технология обработки данных.
Для понимания принципов функционирования СУБД представляется целесообразным рассмотреть архитектурные механизмы такой системы. Под
архитектурой СУБД понимается совокупность ее основных функциональных компонентов, а также средств обеспечения и взаимодействия этих компонентов друг с другом, с пользователями и системой. Одной из наиболее важных функций СУБД, лежащей в основе сложившегося похода к архитектуре таких систем, является обеспечение возможностей абстракции данных. Именно механизмы данных, предоставляемые СУБД, позволяют различать и поддерживать два независимых взгляда на базу данных – взгляд пользователя, воплощаемый в логическом представлении данных, и взгляд системы – физическое представление, характеризующее организацию хранимых данных.
Определение. Функциональный компонент СУБД, механизмы которого служат для поддержки некоторого уровня абстракции данных, называют архитектурным уровнем. Комитет по планированию стандартов Американского национального института стандартов (ANSI/SPARC) (American National Standards Institute on Computers and Information Processing / Standards Planning and Requirements Committee) предложил обобщенную трехуровневую модель архитектуры СУБД. Это следующие уровни:
внешний уровень наиболее близок к пользователям, т.е. он связан со способами представления данных для отдельных пользователей;
концептуальный уровень связан с обобщенным представлением пользователей;
внутренний уровень – это уровень, близкий к физическому хранению, т.е. связанный со способами сохранения информации на физических устройствах хранения;
Может быть несколько внешних представлений, каждое из которых состоит из более или менее абстрактного представления определенной части базы данных, и может быть только одно концептуальное представление, состоящее из абстрактного представления базы данных в целом. Также единственно и внутреннее представление, отражающее всю базу данных как физически хранимую. Рассмотрим схему функционирования и взаимодействия этих компонентов архитектуры (Рисунок 1.2).
^ Внешний уровень – это индивидуальный уровень пользователя. Таким пользователем может быть прикладной программист, конечный пользователь с любым уровнем профессиональной подготовки, администратор базы данных. У каждого пользователя есть свой язык. Для прикладного программиста это язык рассматриваемой системы, например FoxPro. Для конечного пользователя это или специальный язык запросов, или язык экранных форм, меню, созданный с учетом требований пользователя. Для администратора базы данных - это первые два вида языка и язык операционной системы. Все эти языки включают подъязык данных, т.е. подмножество операторов всего языка, связанное только с объектами и операциями баз данных.
система управления базами данных
Рисунок 1.2 Детализированная архитектура системы управления базами данных
Подъязык данных встроен в базовый язык, который обеспечивает также и не связанные с базами данных возможности, например вычислительные операции. Система может поддерживать любое количество базовых языков и подъязыков данных. Однако существует один язык, который поддерживается практически всеми сегодняшними системами – это SQL (Structured Query Language) («эс-кью-эль»). На сегодняшний день этот язык является официальным стандартом языка для работы с реляционными системами.
^ Концептуальный уровень. Концептуальное представление – это представление всей информации баз данных на концептуальном уровне. Для отображения концептуального представления используется концептуальная схема, которая использует другой язык определения данных – концептуальный. В рассмотрение концептуального языка нельзя включать рассмотрение структуры хранения, методов доступа, не должно быть никакого упоминания о представлении хранимого файла, индексировании. Определения концептуального языка должны относиться только к содержанию информации. Определения концептуального языка могут включать информацию о дополнительных средствах, таких как средства безопасности или правила для обеспечения целостности. Конечной целью концептуальной схемы, например, может быть описание всего предприятия – не только самих его данных, но также и того, как эти данные используются: как они перемещаются внутри предприятия, для чего используются в каждом конкретном месте, какая ревизия или иной контроль применяется к ним в каждом отдельном случае.
Внутренний уровень представляется в виде внутренней схемы, которая определяет не только различные типы хранимых записей, но также существующие индексы, способы представления хранимых записей, физическую последовательность записей.
^ Администрирование базами данных. Администрирование базами данных предусматривает выполнение функций, направленных на обеспечение надежного и эффективного функционирования системы баз данных, адекватности содержания базы данных информационным потребностям пользователей, отображения в базе данных актуального состояния предметной области. Именно с признанием концепции многоуровневой архитектуры СУБД появилась необходимость в четком понимании и структуризации функций персонала, занятого администрированием данными в системах баз данных. Различают два вида персонала, связанных с администрированием. Администратор данных (АД) – это специалист, отвечающий за стратегию и политику принятия решений, связанных с данными предприятия, а администратор базы данных (АБД) – это специалист, обеспечивающий необходимую техническую поддержку выполнения этих решений.
Рассмотрим функции администрирования баз данных:
определение концептуальной схемы. АД определяет объекты, в которых заинтересовано предприятие, а также информацию об этих объектах (логическое проектирование). АБД создает соответствующую концептуальную схему;
определение способов представления данных в хранимой базе данных (т.е. в памяти) (физическое проектирование);
взаимодействие с пользователями. Это и обеспечение необходимой информацией конечного пользователя о функциях приложения, помощь в выявлении и решений проблем;
определение правил безопасности и целостности;
определение процедур резервного копирования и восстановления;
управление производительностью и реагирование на изменяющиеся требования.
^ Клиент-серверные технологии. Распределенная технология обработки данных. Выполнение работ на данном этапе предусматривает выявление характеристик, как ЭВМ, так и возможностей СУБД по следующим двум направлениям:
Изучение операционной обстановки ЭВМ.
Характеристики производительности непосредственно самой СУБД.
1 направление охватывает круг вопросов, связанных с выявлением характеристик ЭВМ: версия ОС, объем ОП, объем ВП (винчестер) и наличие парка машин в условиях работы в локальной сети. В современных ИС перспективным является разработка программных пакетов в корпоративных системах, в которых очень важным представляется вопрос выбора архитектуры.
2 направление охватывает широкий круг вопросов, связанных с выявлением применимости тех или иных возможностей самой СУБД для реализации поставленной задачи.
К таким характеристикам относятся:
Ограничения СУБД к объему БД реальной системы.
Сетевые возможности СУБД.
Средства обеспечения безопасности и требуемого уровня конфиденциальности в зависимости от степени критичности данных.
Наличие в СУБД инструментария (мастеров, дизайнеров, конструкторов), позволяющего облегчить процесс разработки и дальнейшей модификации программ.
Наличие инструментария для администрирования БД.
Согласно рекомендации международных организаций по разработке стандартов (ANSI — American National Standard Institute, SPARC — Standard Planning And Requirements Committed) в области информационных технологий наиболее широко применяемой и практически удобной является клиент-серверная архитектурная модель СУБД.
Клиент — это такой компонент СУБД, который обеспечивает оперативную обработку данных прикладной программы, реализует интерфейс с конечным пользователем и формирует запросы серверу.
Сервер — это компонент СУБД, обеспечивающий удовлетворение запросов клиента, хранение и накопление информации в БД, безопасность и защиту важной информации.
Для лучшего понимания различных вариантов реализации клиент-серверной архитектуры СУБД рассмотрим следующие ее схемы:
Так как система в целом может быть четко разделена на две части (сервер и клиенты), появляется возможность работы этих двух частей на разных машинах. Иначе говоря, существует возможность распределенной обработки. Каждый сервер может обслуживать много клиентов, а каждый клиент может работать так, как будто он имеет дело с одним сервером на одной машине, невзирая на тот факт, что серверы могут размещаться на нескольких машинах, в таком случае мы имеем настоящую распределенную систему баз данных.
Лекция№ 3 Тема: Проектирование БД.
Модели данных Нормализация отношений Механизмы обеспечения целостности БД^ Основные вопросы: Иерархическая, сетевая и реляционная модели данных. Реляционное исчисление и реляционная алгебра Виды отношений. Дублирование информации в базе данных. Нормальные формы Представления.Триггеры. Хранимые процедуры. Механизм транзакций
Один из основных принципов технологии баз данных заключается в том, что на основе построенной инфологической модели предметной области должна быть разработана конкретизированная до экземпляров объектов и связей модель, которая должна поддерживаться на ЭВМ и динамически изменяться в соответствии с изменениями состояний предметной области, возможно с некоторым запаздыванием во времени. Эта модель есть модель баз данных. Любая модель баз данных в основе опирается на какую-либо модель данных.
Модели данных. Если за основу классификации взять структуру организации данных, то различают следующие виды моделей данных:
реляционная
иерархическая (древовидная)
сетевая
Реляционная модель является простейшей и наиболее привычной формой представления данных в виде таблиц. В теории множеств таблице соответствует термин отношение(relation), который и дал название модели. К этой модели мы вернемся для более детального рассмотрения в виду практической значимости и распространенности.
^ Иерархическая модель данных базируется на использовании графовой и табличной форм представления данных. В графической диаграмме модели вершина графа используется для интерпретации типов сущностей, а дуги для интерпретации типов связей между типами сущностей. При реализации вершины представляются таблицами описания экземпляров сущностей соответствующего типа.
Структуру иерархической модели можно рассматривать как рекурсивное дерево.
^ Рекурсивное дерево определяется как конечное множество Т, состоящее из одного или более узлов-вершин, таких, что:
существует один специально выделенный узел, называемый корнем;
остальные узлы разбиты на М не пересекающихся подмножеств Т1, Т2, ..., Тm, каждое из которых в свою очередь является деревом.
Из определения дерева следует, что любой узел дерева является корнем некоторого поддерева, содержащегося в полном дереве. Число поддеревьев узла называют
степенью узла. Узел называется
концевым, если он имеет нулевую степень. Иногда концевые узлы называют
листьями, а ребра
ветвями. Узел, не являющийся ни корнем, ни концевым узлом, называется
узлом ветвления.
Древовидная модель или структура данных имеет следующие свойства:
иерархия всегда начинается с корневого узла;
на первом уровне иерархии может находиться только корневой узел;
на нижних уровнях находятся порожденные узлы;
каждый порожденный узел, находящийся на уровне i, связан только с одним непосредственно исходным узлом, находящимся на более верхнем i-1 уровне иерархии;
каждый исходный узел может иметь один или несколько непосредственно порожденных узлов, называемых подобными;
доступ к каждому порожденному узлу выполняется через его непосредственно исходный узел;
существует единственный иерархический путь доступа к узлу, начиная от корня дерева.
Рассмотрим компоненты модели на теоретико-множественном уровне.
В программировании подобные модели используются при разработке рекурсивных алгоритмов. В повседневной человеческой деятельности иерархические структуры широко используются при создании классификаторов, ускоряющих поиск требуемой информации, а также при проектировании структур управления.
^ Сетевая модель данных. Сетевые модели также базируются на использовании графовой формы представления данных. Отличие ее структуры от древовидной в наличии связей «всех со всеми». На рисунке представлена схема сетевой модели.
Вернемся к рассмотрению реляционной модели данных. Теоретической основой современной технологии баз данных является именно реляционная модель, предложенная Е.Коддом в 1970 году. Для описания этой модели имеется мощный математический аппарат – реляционное исчисление и реляционная алгебра, где для баз данных определены хорошо известные теоретико-множественные операции. Прежде всего ознакомимся со специальной терминологией теории реляционной модели, необходимой для лучшего понимания вопросов, связанных с проектированием баз данных.
Схему реляционной модели можно представить следующим образом:
степень
-
А
В
С
D
A1
B1
C1
D1
A2
B2
C2
D2
...
...
...
...
An
Bn
Cn
Dn
Определение. Реляционная модель данных представляет множество отношений, над которыми могут выполняться операции реляционной алгебры или реляционного исчисления. Реляционная алгебра предоставляет в явном виде набор операций (соединение, объединение, декартово произведение), которые можно использовать, чтобы сообщить системе, как в базе данных из определенных отношений реально построить необходимое отношение. Реляционное исчисление представляет собой систему обозначений для определения необходимого отношения в терминах данных отношений. Формулировка запроса в терминах исчисления носит описательный характер, а алгебраическая формулировка – предписывающий. В исчислении просто описывается, в чем заключается проблема, а в алгебре описывается процедура решения этой проблемы.
Для более эффективного уяснения формальных терминов реляционной модели дадим пояснения к элементам схемы следующей таблицей соответствия:
Таблица 2 Соответствие терминов теории реляционной модели и реляционной таблицы
формальный реляционный термин
неформальный эквивалент
отношение
таблица
кортеж
строка таблицы
атрибут
столбец таблицы
кардинальное число
количество строк
степень отношения
количество атрибутов
первичный ключ
уникальный идентификатор, по которому осуществляется связь отношений
домен
общая совокупность допустимых значений атрибута
Термины «отношение» и «таблица» не идентичны. Скорее, таблица – это одна из форм представления отношения.
Отношение – это абстрактный вид объекта, а
таблица – это конкретное изображение этого абстрактного объекта. Если степень отношения равна 1, то отношение называется унарным. Если степень равна 2, то отношение – бинарное, степень- n, то отношение – n-арное.
^ Нормализация отношений. Процесс уменьшения избыточности информации в базе данных называется нормализацией. В теории нормализации баз данных разработаны достаточно формализованные подходы по разбиению данных, обладающих сложной структурой, на несколько таблиц. Теория нормализации оперирует с пятью основными нормальными формами таблиц. Взаимное соотношение этих форм можно представить следующей схемой:
Рис. 3.1 Нормальные формы
Первая нормальная форма таблицы. Таблица находится в 1НФ, если она удовлетворяет следующим требованиям:
не имеет повторяющихся записей;
отсутствуют повторяющиеся группы полей;
строки не упорядочены;
столбцы не упорядочены.
Вторая нормальная форма таблицы. Таблица находится в 2НФ, если она удовлетворяет следующим требованиям:
удовлетворяет условиям 1НФ;
любое неиндексное поле однозначно идентифицируется полным набором индексных полей.
Третья нормальная форма таблицы. Таблица находится в 3НФ, если она удовлетворяет следующим требованиям:
удовлетворяет условиям 2НФ;
ни одно из неиндексных полей не идентифицируется с помощью другого неиндексного поля.
Процесс перехода таблиц из одной нормальной формы к другой осуществляется разбиением их на более мелкие таблицы вводом индексного поля. Требование нормализации не является обязательным для всех таблиц. После определения структуры мелких таблиц, появившихся в результате нормализации, отношений между ними и совпадающих полей, которые будут использованы для связывания, можно приступать к формированию базы данных.
^ Механизмы обеспечения целостности БД. Проектирование структур баз данных является одним из очень важных этапов в процессе разработки автоматизации информационной системы. Важность данного этапа особенно остро проявляется при разработки пакетов прикладных программ, автоматизации деятельности сложных современных систем. Порой происходит так, что при модификации разработки программных модулей начинают осознавать непродуманность структуры базы данных на предыдущем этапе. Чтобы не было таких моментов, специалисты рекомендуют по мере необходимости применять методы проектирования оптимальных структур баз данных.
Методы проектирования оптимальных структур данных:
индексированный;
транзакция;
нормализация отношений;
создание и использование представлений;
механизм баз данных.
Целью применения этих методов является достижение следующих результатов:
обеспечение ускоренного доступа к данным;
контроль за целостностью баз данных;
рациональное использование дискового пространства;
исключение дублирования информации.
Далее рассмотрим возможность достижения указанных целей теми или иными методами. Как мы уже знаем, индексирование в отличие от обычной сортировки обеспечивает рациональное использование дискового пространства и за счет постоянной связи с исходной таблицей можно получить ускоренный доступ к данным. Известен также механизм транзакции, позволяющий контролировать целостность баз данных.
Метод нормализации отношений позволяет избежать излишнего дублирования информации в таблице, тем самым обеспечивает рациональное использование дискового пространства. В будущем проанализируем методы создания и использования представлений и механизм базы данных, важным достоинством которых является обеспечение целостности базы данных. Механизм представлений позволяет достичь ускоренного доступа к данным.
Лекция №4Тема: Основные функции современной СУБД.
^ SQL-запросы. Отчеты и экранные формы. Разработка и компоновка элементов готового приложения Основные вопросы: Структура SQL. Проектирование интерфейса конечного пользователя с прикладной программой. Анализ данных. Менеджер проектов. Компиляция проекта.
SQL является стандартным реляционным языком и в настоящее время поддерживается практически всеми продуктами, представленными на рынке, поэтому каждый специалист, интересующийся базами данных, должен быть знаком с ним. Те языки, которые обычно поддерживаются программными продуктами, можно назвать «надмножествами подмножества» языка SQL, другими словами, любой данный продукт, не поддерживая некоторых аспектов стандарта, в других отношениях, возможно, превосходит его. Впервые этот язык в СУБД стал применяться в 1981году. SQL можно использовать для:
определения данных (создание и удаление таблиц и индексов)
манипуляции с данными (выборка и модификация)
администрирования базы данных (определение списка пользователей, назначение прав доступа.
Преимущества использования SQL:
поддерживается многими поставщиками СУБД. Программы, написанные с использованием языка SQL, будут работать почти на любом сервере базы данных;
прост в изучении.
По структуре SQL состоит из двух подчиненных языков: языка определения данных (DDL) и языка манипулирования данными (DML).
Язык DDL включает определение и объявление объектов базы данных. Язык DML рассматривает операторы выборки и манипулирования данными.
Язык DDL включает определение и объявление объектов базы данных. Язык DML рассматривает операторы выборки и манипулирования данными. Рассмотрим синтаксисы команд с примерами.
Таблица 1 Перечень основных команд SQL
тип команды
назначение
синтаксис
пример
DDL
Создание таблиц
CREATE TABLE имя таблицы (определение поля [определение поля]...)
^ CREATE TABLE ABITUR
(KOD_RCT CHAR(11) NOT NULL, FIO_ABITUR CHAR(30), SPECIAL CHAR(6) NOT NULL,
... LGOT CHAR(20))
тип команды
назначение
синтаксис
пример
DDL
Создание индексов
CREATE [UNIQUE] INDEX имя индекса
ON имя таблицы
поле таблицы [ASC!DESC]
поле таблицы [ASC!DESC]…]
(обеспечивает ускоренный доступ к данным и уникальность записей)
USE CUST
INDEX ON Ccust_id TAG CUSTID OF CUST
INDEX ON Clast TAG CUSNAME OF CUST
открытие созданных индексных файлов:
^ USE CAST INDEX CUSTID, CUSTNAME
DDL
Удаление таблиц и индексов
DROP TABLE имя таблицы
DROP INDEX имя индекса
^ DROP TABLE ABITUR
DDL
Изменение структуры таблицы
ALTER TABLE имя таблицы
ADD определение поля
[ , определение поля]…
DROP имя поля
[ , имя поля]…
RENAME старое имя поля-новое имя поля
[ , старое имя поля-новое имя поля]…
MODIFY определение поля
[ , определение поля]…
^ MODIFY STRUCTURE
DML
выборка данных из таблиц
SELECT [DISTINCT] список выбираемых полей
FROM список таблиц
[WHERE условие выборки]
[GROUP BY условие группировки
[HAVING условие выборки группы ]]
[ORDER BY условие упорядочивания]
[[INTO имя таблицы]
[TO FILE имя файла [ADDITIVE ]! TO PRINTER]]
^ SELECT FIO, SPECIAL
FROM ABITUR
WHERE RAION=”Зайсанский”
SELECT ABITUR.FIO, ABITUR.SPECIAL FROM ABITUR
WHERE RAION=”Зайсанский”
ключевое слово DISTINCT исключает выбор дубликатов
^ SELECT NAME_PROD, KOL_PROD, KOL_PROD*CENA AS SUMMA INTO OTCHET
DML
выборка вычисляемых значений
KADRY.OKLAD*0.10
KOL_PROD*CENA
SELECT KADRY.FIO, “оклад”,KADRY.OKLAD, “10 % с оклада”, KADRY.OKLAD*0.10
^ FROM KADRY
DML
ограничение выборки
WHERE условие выборки
SELECT ABITUR.FIO, ABITUR.SPECIAL FROM ABITUR
WHERE RAION=”Зайсанский”
^ AND TESTRES>=40
DML
выборка с упорядочением
последнюю строчку ПРИМЕРА можно записать и так:
ORDER BY 2 DESC
^ SELECT ABITUR.FIO, ABITUR.TESTRES FROM ABITUR
WHERE NAME_SP=”Прикладная математика”
AND TESTRES>=40
ORDER BY TESTERS DESC
DML
выборка с использованием BEETWEEN
можно использовать условие NOT BEETWEEN (не принадлежащее диапазону между)
^ SELECT ABITUR.FIO, ABITUR.TESTRES FROM ABITUR
WHERE TESTRES BEETWEEN 100 AND 120
DML
выборка с использованием IN
IN (выбираемые значения)
^ SELECT ABITUR.FIO, ABITUR.TESTRES FROM ABITUR
WHERE NAME_SP IN (”Прикладная математика”, “Информатика”, “Информационные системы в бизнесе”)
DML
выборка с использованием шаблонов
имя поля LIKE строковая константа
знак % означает любую последовательность символов
^ SELECT FIO, SPECIAL
FROM ABITUR
WHERE FIO LIKE “Т%”
DML
выборки из связанных таблиц
WHERE условие связывания таблиц, например TABLE1.POLE1=TABLE2.POLE1
^ SELECT ABITUR.FIO, ABITUR.RAION, SPRAV_SP.NAME_SP
FROM ABITUR, SPRAV_SP
WHERE ABITUR.SPECIAL=SPRAV_SP.SPECIAL
тип команды
назначение
синтаксис
пример
DML
вычисление групповых значений
SELECT COUNT (*) FROM имя таблицы
SUM
AVERAGE
MAX
MIN
SELECT COUNT (*) FROM ABITUR – подсчитывает количество абитуриентов, подавших заявления
DML
использование группировки данных
вычисление групповых значений для заданных групп
GROUP BY имя поля
если поле по значениям которого осуществляется группирование, содержит неопределенные значения, то каждое из них порождает отдельную группу.
^ SELECT OTDEL_M, SUM(QUANT)
FROM PRODAG
GROUP BY OTDEL_M – общий объем продаж товара
DML
использование HAVING
этот оператор используется для того, чтобы исключать группы точно также, как WHERE используется для исключения записей.
^ SELECT OTDEL_M, SUM(QUANT)
FROM PRODAG
GROUP BY OTDEL_M
HAVING ID_PROD=”Нестерова”
DML
удаление записей
DELETE
FROM таблица
[WHERE условие]
DELETE
^ FROM ABITUR
WHERE KOD_RCT=”01101121323”
DML
добавление записей
INSERT
INTO таблица [(поле [, поле ]...)]
VALUES (константа [, константа]...)
вставка множества записей:
INSERT
^ INTO ABITUR
FROM ABITUR1
INSERT
INTO ABITUR (KOD_RCT, FIO, SPECIAL, TESTRES)
VALUES (“01101121323”, “Сергеев Игорь Дмитриевич”, “010240”, 95
INSERT
INTO ABITUR
VALUES (“01101121323”, “Сергеев Игорь Дмитриевич”, “010240”, 95
^ Отчеты и экранные формы
Определение отчета, назначение: Отчет - форматированное представление данных, выводимое на экран, принтер или в файл. Достоинство отчета - оформление данных в наиболее наглядной, удобной для просмотра, анализа форме. Средство FoxPro, позволяющее формировать гибкие, легко модифицируемые отчеты, называется конструктором отчета (
Report Writer, Report Builder).
Определение экранной формы, структура и назначение. Экранная форма – это средство представления информации на экране в наглядном, удобном для пользователя формате. Подобно тому как Windows является средой взаимодействия пользователя с ЭВМ, в целом экранные формы выступают как средства взаимодействия пользователя с тем или иным прикладным программным пакетом, реализующим решение задачи в какой – либо сфере практической деятельности человека. В отличие от других функциональных средств, которыми располагает VfoxPro, возможности экранной формы чрезвычайно широки. Любая экранная форма состоит из двух компонентов:
контейнера, представляющего фоновый компонент для всех элементов управления экранной формой;
элементов управления – наполнителей экранной формы, определяющих содержание, назначение и функции создаваемой экранной формы
Методы создания экранных форм. Создание экранных форм можно реализовать следующими методами:
мастером экранных форм Form Wizard;
построителем или конструктором экранных форм Form Designer;
средством Quick Screen
Мастер Form Wizard позволяет быстро построить экранные формы стандартной конфигурации, в которые включаются средства для редактирования данных и навигации по записям. Мастер Form Wizard имеет смысл использовать для создания простых в части выполняемых функций экранных форм или для построения прототипа формы, который в дальнейшем можно откорректировать с помощью Form Designer.
Те инструментальные средства, которые доступны при работе с Form Designer и применяются для создания и настройки отдельных элементов управления, в значительной мере облегчают задачу программиста.
Quick Screen позволяет строить упрощенные формы для просмотра данных.
Разработка и компоновка элементов готового приложенияМенеджер проектов – это специальный компонент, позволяющий объединить все элементы готового приложения в единый проект и осуществляющий централизованное управление им. Использование Project Manager серьезно облегчает решение задач управления и сопровождения готового приложения.
Основные преимущества применения проекта выявляются,
во-первых, как единого организующего центра управления современным приложением, которое включает несколько десятков файлов;
во вторых, современное приложение доходит до заказчика в виде выполняемых файлов (EXE или APP), а Project Manager в значительной мере берет на себя их формирование;
в-третьих, Project Manager обладает большим набором инструментальных средств, значительно облегчающих работу разработчика.
^ Структура проекта. Создание проекта начинается с выбора команды
File-New- опция
Project – кнопка (
New File), кнопка (
Wizard). Структура создаваемого проекта (Рисунок 2.5) организована в виде иерархического дерева, каждую ветвь которого можно развернуть, аналогично многим известным системным средствам типа Explorer.
^
Рисунок 2.5 Окно создаваемого проекта
На вкладке ALL представлены все компоненты проекта. Вкладка
DATA объединяет все таблицы баз данных, необходимых для работы проекта. Вкладка DOCUMENTS – файлы экранных форм, отчетов,
CLASSES – библиотека классов (других проектов),
CODES – файлы программ,
OTHER – файлы изображений, меню, текстовые файлы.
Кнопка BUILD в правой части окна проекта предназначена для формирования файла приложения или выполняемого файла из всего набора компонентов проекта. Нажатие этой кнопки приводит к открытию диалогового окна (Рисунок 2.6). Рассмотрим предлагаемые опции.
Rebuild Project – при выборе этой опции просматриваются все файлы проекта, нужные компилируются и проверяется наличие синтаксических ошибок. При этом формируются файлы .PJX – в виде таблицы,.PJT – мемо-файл;
Build Application – при выборе этой опции строится проект, к нему привязываются все файлы, помеченные для включения в APP-файл. Для работы с созданным APP- файлом необходимо, чтобы на компьютере
Build Executable – при выюоре этой опции создается EXE – файл. Для работы с созданным EXE файлом необходимо, чтобы на компьютере были установлены библиотека времени выполнения Visual FoxPro и другие необходимые DLL – и FLL – файлы.
Build COM DLL – при выборе этой опции создается файл динамически связываемой библиотеки. В результате другие приложения смогут использовать этот файл в качестве COM – сервера.
Рисунок 2.6 Окно выбора опций компиляции проекта
^ Главный файл программы. При запуске на выполнение скомпилированного проекта, т.е. EXE – или APP – файла, самой первой вызывается главный файл приложения, который выделен полужирным шрифтом в списке файлов проекта (вкладка Codes). Хотя в принципе это может быть не только файл программы, но и файл экранной формы или меню. Например самая простая главная программа может выглядеть следующим образом:
Do MainMenu.MPR && меню
Do Form Startup.SCX &&начальная экранная форма
Read Events &&внутренний цикл обработки событий
При необходимости назначение файлу статуса главного производится командой
Project – Set main...