Вычисляемые поля
Вычисляемые поля существенно облегчают разработку приложений баз данных, т. к. позволяют получать новые данные на основе существующих, не изменяя при этом структуру таблиц БД. Выражения для получения значений вычисляемых полей разработчик должен разместить в методе-обработчике OnCalcFields набора данных. Здесь можно использовать любые арифметические, логические операции и функции, любые операторы языка, свойства и методы любых компонентов, в том числе запросы SQL:
procedure TForml.TablelCalcFields(DataSet: TDataSet)
; begin
with Tablel do
TabielCalcFieldl.Value := Fields[0].Value + Fields[1].Value;
with Queryl do
begin
Params[0].AsInteger := Tablel.Fields[0].Aslnteger;
Open;
TabielCalcFieldl.Value := Fields[0].AsString;
Close;
end;
end;
Метод OnCalcFields выполняется при открытии набора данных, при переходе в режим редактирования, при передаче фокуса между компонентами отображения данных или колонок сетки, при удалении записи. Но для этого нужно, чтобы свойство AutoCaicFields набора данных было равно значению True.
Примечание
Необходимо учитывать, что сложные вычисляемые поля могут существенно замедлить работу набора данных (особенно при использовании при этом запросов SQL). Кроме того, в процессе редактирования набора данных (при изменении значения поля, сохранении изменений и переходе на следующую запись) вычисляемые поля рассчитываются несколько раз подряд. Для уменьшения числа автоматических обращений к методу OnCalcFields нужно использовать свойство AutoCaicFieids := False.
Для создания вычисляемого поля достаточно в диалоге создания нового поля Редактора полей в качестве типа поля задать "вычисляемое", в остальном процесс совпадает с созданием поля данных.
В выражениях вычисляемых полей можно использовать другие вычисляемые поля, но они обязательно должны быть определены в методе OnCalcFields до этого.
Вычисляемые поля нельзя использовать при фильтрации набора данных при помощи метода-обработчика onFilterRecord, т. к. он вызывается до метода-обработчика OnCalcFields, а вычисляемые
Экзаменационный билет №13
1) Свойства отношений непосредственно следуют из приведенного выше определения отношения. В этих свойствах в основном и состоят различия между отношениями и таблицами.
В отношении нет одинаковых кортежей. Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы (см. понятие множества в гл.1.). Таблицы в отличие от отношений могут содержать одинаковые строки.
Кортежи не упорядочены (сверху вниз). Действительно, несмотря на то, что мы изобразили отношение "Сотрудники" в виде таблицы, нельзя сказать, что сотрудник Иванов "предшествует" сотруднику Петрову. Причина та же - тело отношения есть множество, а множество не упорядочено. Это вторая причина, по которой нельзя отождествить отношения и таблицы - строки в таблицах упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке.
Атрибуты не упорядочены (слева направо). Т.к. каждый атрибут имеет уникальное имя в пределах отношения, то порядок атрибутов не имеет значения. Это свойство несколько отличает отношение от математического определения отношения (см. гл.1 - компоненты кортежей там упорядочены). Это также третья причина, по которой нельзя отождествить отношения и таблицы - столбцы в таблице упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке.
Все значения атрибутов атомарны. Это следует из того, что лежащие в их основе атрибуты имеют атомарные значения. Это четвертое отличие отношений от таблиц - в ячейки таблиц можно поместить что угодно - массивы, структуры, и даже другие таблицы.
Замечание. Из свойств отношения следует, что не каждая таблица может задавать отношение. Для того, чтобы некоторая таблица задавала отношение, необходимо, чтобы таблица имела простую структуру (содержала бы только строки и столбцы, причем, в каждой строке было бы одинаковое количество полей), в таблице не должно быть одинаковых строк, любой столбец таблицы должен содержать данные только одного типа, все используемые типы данных должны быть простыми.
Замечание. Каждое отношение можно считать классом эквивалентности таблиц, для которых выполняются следующие условия:
Таблицы имеют одинаковое количество столбцов.
Таблицы содержат столбцы с одинаковыми наименованиями.
Столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов.
Таблицы имеют одинаковые строки с учетом того, что порядок столбцов может различаться.
Все такие таблицы есть различные изображения одного и того же отношения.
2) 43 Создание полей типа "LookUp" d Delphi.
Для чего нужны lookup-поля, поясним на примере. Допустим, имеется две таблицы БД: таблица "Заказы" с полями N, Date, ClientID, Amount и таблица "Клиенты" с полями ID, Name, Address. В таблице "Заказы" содержится информация о заказах (номер, дата, идентификатор клиента, сделавшего заказ, и сумма заказа). В таблице "Клиенты" содержится информация о клиентах (идентификатор клиента, полное наименование, адрес).
Чтобы сформировать простейший отчет по таблице "Заказы" вида Номер заказа - Дата - Наименование клиента - Сумма, потребуется связать обе таблицы по полям ClientID -> ID. Эта задача решается путем создания lookup-поля, которое добавляется к таблице "Заказы" и представляет собой ссылку на поле Name таблицы "Клиенты".
Диалог создания lookup-поля доступен из редактора полей.
Для создания lookup-поля надо указать его имя и тип, а также размер (в случае, если выбран строковый тип). Далее необходимо заполнить следующие поля:
Ключевое поле - поле в исходном наборе данных, которое следует рассматривать как ссылку на поле из lookup-набора. В нашем примере это будет поле ClientID.
Источник данных - lookup-набор данных.
Lookup ключ - поле в lookup-наборе, являющееся ключевым. В нашем примере это поле ID.
Результирующее поле - поле lookup-набора, которое надо подставить в исходный набор данных. В нашем примере это поле Name.
После этого в таблице "Заказы" создается фиктивное поле с заданным именем, которое содержит расшифровку поля ClientID. К нему можно обращаться как к обычному полю, но только для чтения.
Кроме обычных полей и вычисляемых полей, в Delphi имеется возможность создания полей выбора данных (Lookup-полей).
Поле выбора данных одного НД содержит значения из другого набора данных, связанных по ключу с НД, к которому принадлежит это поле. Первый НД - родительский, а второй - дочерний. Lookup-поля и специализированные компоненты TDBLookupListBox, TDBLookupComboBox используют схожий механизм, основанный на реляционной связи двух НД, однако эти компоненты выбора не создают новых полей.
В нашей программе FIRMA в таблице наименования товара содержится поле NSklad (номер склада). Давайте дополним наше приложение таким образом, чтобы при выборе записи из таблицы "Наличие товара" как дополнительная информация выводился бы номер склада, на котором этот товар находится.
Создайте новое поле в НД Table2 с именем NSklad типа Integer. Установите переключатель в положение Lookup. После выбора переключателя становятся доступными элементы группы Lookup definition, с помощью которых устанавливаются параметры связи наборов данных (рисунок 1 и таблица 1).
Рис.1.
Диалоговое окно New
Field
Таблица 1. Параметры связи наборов данных |
|
Название |
Назначение |
DataSet |
Определяет имя родительского НД |
Key Fields |
Определяет список ключевых полей родительского НД. По этим полям построен индекс для связи родительского НД с дочерним. Если в индексе несколько полей, они разделяются точками с запятыми |
Lookup Fields |
Определяет список ключевых полей дочернего НД. По этим полям построен индекс для связи дочернего НД с родительским |
Result Fields |
Поле родительского НД, возвращаемое в качестве результата. Необходимо следить, чтобы тип вновь создаваемого поля совпадал с типом указанного здесь поля |
Установите у этих элементов следующие значения:
Таблица 2. Значения свойств |
|
Элемент |
Значение |
DataSet |
Table1 |
Key Fields |
Naim |
Lookup Fields |
Naim |
Result Fields |
NSklad |
Таким образом, родительский НД Table1 связан с дочерним НД Table2 по полю Naim, и создаваемому нами полю присваивается значение из поля NSklad НД Table1.
Выберите в редакторе полей НД Table2 созданный вновь объект TField NSklad и присвойте его свойству Visible значение False (таким образом, поле NSklad не будет отображаться в DBGrid2). Поместите на форму компонент TLabel с вкладки Standard, TDBText с вкладки Data Controls, присвоив их свойствам следующие значения:
DBText1 |
|
DataSource |
DataSource2 |
DataField |
NSklad |
Label1 |
|
Caption |
Номер склада |
Запустив программу, вы убедитесь, что при перемещении по таблице "Наличие товара", в DBLabel1 показывается номер склада, на котором находится этот товар. Как видно, значение берется из Table1 (рисунок 2).
Рис.2.
Приложение с Lookup-полем
Созданное приложение можно взять здесь.
С помощью Lookup-полей можно не только показывать дополнительную информацию из другого НД, но и использовать их для автоматической установки нового значения в другое поле НД.
Изменим нашу БД таким образом: пусть каждый товар будет находиться на отдельном складе с номерами 1, 2, 3 и т.д. Свойство Visible компонента TField NSklad установите в True. Теперь в DBGrid2 отображается номер склада, на котором находится товар, а при редактировании этого поля появляется комбинированный список и после выбора значения автоматически обновляется поле Naim. Заметим, что список выбора раскрывается, несмотря на то, что свойство ReadOnly (только чтение) компонента DBGrid2 установлено в True.
Рис.3.
Результат работы приложения
Экзаменационный билет №14
1) Труднее всего дать определение вещей, которые всем понятны. Если давать не строгое, описательное определение, то всегда остается возможность неправильной его трактовки. Если дать строгое формальное определение, то оно, как правило, или тривиально, или слишком громоздко. Именно такая ситуация с определением отношения в Первой Нормальной Форме (1НФ). Совсем не говорить об этом нельзя, т.к. на основе 1НФ строятся более высокие нормальные формы, которые рассматриваются далее в гл. 6 и 7. Дать определение 1НФ сложно ввиду его тривиальности. Поэтому, дадим просто несколько объяснений.
Объяснение 1. Говорят, что отношение находится в 1НФ, если оно удовлетворяет определению 2.
Это, собственно, тавтология, ведь из определения 2 следует, что других отношений не бывает. Действительно, определение 2 описывает, что является отношением, а что - нет, следовательно, отношений в непервой нормальной форме просто нет.
Объяснение 2. Говорят, что отношение находится в 1НФ, если его атрибуты содержат только скалярные (атомарные) значения.
Опять же, определение 2 опирается на понятие домена, а домены определены на простых типах данных.
Непервую нормальную форму можно получить, если допустить, что атрибуты отношения могут быть определены на сложных типах данных - массивах, структурах, или даже на других отношениях. Легко себе представить таблицу, у которой в некоторых ячейках содержатся массивы, в других ячейках - определенные пользователями сложные структуры, а в третьих ячейках - целые реляционные таблицы, которые в свою очередь могут содержать такие же сложные объекты. Именно такие возможности предоставляются некоторыми современными пост-реляционными и объектными СУБД.
Требование, что отношения должны содержать только данные простых типов, объясняет, почему отношения иногда называют плоскими таблицами (plain table). Действительно, таблицы, задающие отношения двумерны. Одно измерение задается списком столбцов, второе измерение задается списком строк. Пара координат (Номер строки, Номер столбца) однозначно идентифицирует ячейку таблицы и содержащееся в ней значение. Если же допустить, что в ячейке таблицы могут содержаться данные сложных типов (массивы, структуры, другие таблицы), то такая таблица будет уже не плоской. Например, если в ячейке таблицы содержится массив, то для обращения к элементу массива нужно знать три параметра (Номер строки, Номер столбца, номер элемента в массиве).
Таким образом появляется третье объяснение Первой Нормальной Формы:
Объяснение 3. Отношение находится в 1НФ, если оно является плоской таблицей.
Мы сознательно ограничиваемся рассмотрением только классической реляционной теории, в которой все отношения имеют только атомарные атрибуты и заведомо находятся в 1НФ.
2) SQL является, прежде всего, информационно-логическим языком, предназначенным для описания, изменения и извлечения данных, хранимых в реляционных базах данных. SQL нельзя назвать языком программирования [источник не указан 427 дней].[6]
Изначально, SQL был основным способом работы пользователя с базой данных и позволял выполнять следующий набор операций:
создание в базе данных новой таблицы;
добавление в таблицу новых записей;
изменение записей;
удаление записей;
выборка записей из одной или нескольких таблиц (в соответствии с заданным условием);
а, также, изменение структур таблиц. Со временем, SQL усложнился — обогатился новыми конструкциями, обеспечил возможность описания и управления новыми хранимыми объектами (например, индексы, представления, триггеры и хранимые процедуры) — и стал приобретать черты, свойственные языкам программирования.
При всех своих изменениях, SQL остаётся единственным механизмом связи между прикладным программным обеспечением и базой данных. В то же время, современные СУБД, а, также, информационные системы, использующие СУБД, предоставляют пользователю развитые средства визуального построения запросов.
Каждое предложение SQL — это либо запрос данных из базы, либо обращение к базе данных, которое приводит к изменению данных в базе. В соответствии с тем, какие изменения происходят в базе данных, различают следующие типы запросов:
запросы на создание или изменение в базе данных новых или существующих объектов (при этом в запросе описывается тип и структура создаваемого или изменяемого объекта);
запросы на получение данных;
запросы на добавление новых данных (записей)
запросы на удаление данных;
обращения к СУБД.
Основным объектом хранения реляционной базы данных является таблица, поэтому все SQL-запросы — это операции над таблицами. В соответствии с этим, запросы делятся на
запросы, оперирующие самими таблицами (создание и изменение таблиц);
запросы, оперирующие с отдельными записями (или строками таблиц) или наборами записей.
Каждая таблица описывается в виде перечисления своих полей (столбцов таблицы) с указанием
типа хранимых в каждом поле значений;
связей между таблицами (задание первичных и вторичных ключей);
информации, необходимой для построения индексов.
Запросы первого типа, в свою очередь, делятся на запросы, предназначенные для создания в базе данных новых таблиц, и на запросы, предназначенные для изменения уже существующих таблиц. Запросы второго типа оперируют со строками, и их можно разделить на запросы следующего вида:
вставка новой строки;
изменение значений полей строки или набора строк;
удаление строки или набора строк.
Самый главный вид запроса — это запрос, возвращающий (пользователю) некоторый набор строк, с которым можно осуществить одну из трёх операций:
просмотреть полученный набор;
изменить все записи набора;
удалить все записи набора.
Таким образом, использование SQL сводится, по сути, к формированию всевозможных выборок строк и совершению операций над всеми записями, входящими в набор.
[править]
Описание
Язык SQL представляет собой совокупность
операторов;
инструкций;
и вычисляемых функций.
[править]
Операторы
Согласно общепринятому стилю программирования, операторы (и другие зарезервированные слова) в SQL всегда следует писать прописными буквами[7].
Операторы SQL делятся на:
операторы определения данных (Data Definition Language, DDL)
CREATE создает объект БД (саму базу, таблицу, представление, пользователя и т. д.)
ALTER изменяет объект
DROP удаляет объект
операторы манипуляции данными (Data Manipulation Language, DML)
SELECT считывает данные, удовлетворяющие заданным условиям
INSERT добавляет новые данные
UPDATE изменяет существующие данные
DELETE удаляет данные
операторы определения доступа к данным (Data Control Language, DCL)
GRANT предоставляет пользователю (группе) разрешения на определенные операции с объектом
REVOKE отзывает ранее выданные разрешения
DENY задает запрет, имеющий приоритет над разрешением
операторы управления транзакциями (Transaction Control Language, TCL)
COMMIT применяет транзакцию.
ROLLBACK откатывает все изменения, сделанные в контексте текущей транзакции.
SAVEPOINT делит транзакцию на более мелкие участки.
[править]
Преимущества и недостатки
[править]
Преимущества
[править]
Независимость от конкретной СУБД
Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую. Существуют системы, разработчики которых изначально ориентировались на применение по меньшей мере нескольких СУБД (например: система электронного документооборота Documentum может работать как с Oracle, так и с Microsoft SQL Server и IBM DB2). Естественно, что при применении некоторых специфичных для реализации возможностей такой переносимости добиться уже очень трудно.
[править]
Наличие стандартов
Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка. Правда, стоит обратить внимание, что сам по себе стандарт местами чересчур формализован и раздут в размерах (например, Core-часть стандарта SQL:2003 представляет собой более 1300 страниц текста).
[править]
Декларативность
С помощью SQL программист описывает только то, какие данные нужно извлечь или модифицировать. То, каким образом это сделать, решает СУБД непосредственно при обработке SQL-запроса. Однако не стоит думать, что это полностью универсальный принцип — программист описывает набор данных для выборки или модификации, однако ему при этом полезно представлять, как СУБД будет разбирать текст его запроса. Чем сложнее сконструирован запрос, тем больше он допускает вариантов написания, различных по скорости выполнения, но одинаковых по итоговому набору данных.
[править]
Недостатки
[править]
Несоответствие реляционной модели данных
Создатели реляционной модели данных Эдгар Кодд, Кристофер Дейт и их сторонники указывают на то, что SQL не является истинно реляционным языком. В частности, они указывают на следующие проблемы SQL[8]:
Повторяющиеся строки
Неопределённые значения (nulls)
Явное указание порядка колонок слева направо
Колонки без имени и дублирующиеся имена колонок
Отсутствие поддержки свойства «=»
Использование указателей
Высокая избыточность
В опубликованном Кристофером Дейтом и Хью Дарвеном Третьем Манифесте[9] они излагают принципы СУБД следующего поколения и предлагают язык Tutorial D, который является подлинно реляционным.
[править]
Сложность
Хотя SQL и задумывался как средство работы конечного пользователя, в конце концов он стал настолько сложным, что превратился в инструмент программиста.
[править]
Отступления от стандартов
Несмотря на наличие международного стандарта ANSI SQL-92, многие компании, занимающиеся разработкой СУБД (например, Oracle, Sybase, Microsoft, MySQL AB), вносят изменения в язык SQL, применяемый в разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом, появляются специфичные для каждой конкретной СУБД диалекты языка SQL.
[править]
Сложность работы с иерархическими структурами
Ранее диалекты SQL большинства СУБД не предлагали способа манипуляции древовидными структурами. Некоторые поставщики СУБД предлагали свои решения (например, Oracle использует выражение CONNECT BY). В настоящее время в ANSI стандартизована рекурсивная конструкция WITH из диалекта SQL DB2. В MS SQL Server рекурсивные запросы появились лишь в версии MS SQL Server 2005.
Экзаменационный билет №15
1) Перви́чный ключ (англ. primary key) — минимальное множество атрибутов, являющееся подмножеством заголовка данного отношения, составное значение которых уникально определяет кортеж отношения. На практике термин первичный ключ обозначает поле (столбец) или группу полей таблицы базы данных, значение которого (или комбинация значений которых) используется в качестве уникального идентификатора записи (строки) этой таблицы.
Первичный ключ в таблице является базовым уникальным идентификатором для записей. Значение первичного ключа используется везде, где нужно указать на конкретную запись. На использовании первичных ключей основана организация связей между таблицами реляционной БД. Чтобы организовать между двумя таблицами связь типа «один к одному» или «один ко многим (многие к одному)» в одну из связываемых таблиц добавляют поле (поля), содержащее (-ие) значение первичного ключа записи в связанной таблице (такое поле называют внешним ключом). Для организации связи типа «многие ко многим» создают отдельную таблицу (так называемую «таблицу связи» или «таблицу ассоциации»), каждая запись которой содержит первичные ключи двух связанных записей в разных таблицах.
Вне́шний ключ (англ. foreign key) — понятие теории реляционных баз данных. Внешним ключом называется поле таблицы, предназначенное для хранения значения первичного ключа другой таблицы с целью организации связи между этими таблицами.