Главная форма для работы пользователя

Главная форма для работы пользователя

Создание запроса конструктором

Способы создания нового запроса

Виды запросов

Маски ввода

Поле с подстановкой

Элементы оформления формы

Выбор типа поля

От типа величины зависят действия, которые можно с ней производить.

Создание формы для ввода исходных данных

Форма в рабочем режиме

Запросы

Запрос – набор инструкций (спецификаций), которые определяют структуру и вид информации, которую требуется найти в базе данных.

Результат работы запроса

Результат работы запроса с использованием условия отбора по сумме продаж

Результат работы запроса с использованием условия отбора по товару

(режим конструктора)

(Рабочий режим)

Например, с числовыми величинами можно выполнять арифметические операции, а с символьными и логическими — нельзя.

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

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

Достоинства:

естественность описания иерархических данных;

высокая эффективность работы, быстродействие.

Недостатки:

жесткость структуры, ограниченная реализация, физическая и

логическая независимость;

ассиметрия представления данных, не являющихся иерархическими;

сложность операций корректировки;

в СУБД ИТ для реализации запроса требуется писать программы (СУБД

для программиста).

Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" – поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база – это самый верный способ потерять данные".

Достоинства:

большая гибкость по сравнению с иерархическими СУБД;

высокая эффективность;

наличие стандартов.

Недостатки:

жесткость структуры;

высокая сложность. (Недостатки такие же, как и в СУБД ИТ)

Сегодня наиболее распространены реляционные модели. Основы реляционной модели данных были впервые изложены в статье Е. Кодда в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К. Дейту.

Согласно Дейту, реляционная модель состоит из трех частей:

· структурной части.

· целостной части.

· манипуляционной части.

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

Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Это целостность сущностей и целостность внешних ключей.

Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление.

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

Достоинства:

1) простота, наглядность, развитый мат аппарат, развитые языковые средства.

Недостатки:

более низкая эффективность по сравнению с сетевыми и иерархическими моделями;

данные представляются на несколько таблиц:

а) данные представляются не в целом виде (не в естественном виде),

б) при работе с этими данными требуется их постоянная сборка.

10.3. Двенадцать правил Кодда

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

12 Правил Кодда

1. Правило информации – вся информация в БД представляется исключительно на логическом уровне в виде таблиц.

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

3. Правило поддержки NULL значений – поддержка недействительных значений, которое отличается от строки символов нулевой длинны, строки пробелов, нулей числовых полей и т.д.

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

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

6. Правило обновления представлений – все представления, которые теоретически можно обновить должны быть доступны.

7. Правило корректировки – обновление, добавление, удаления – должна существовать возможность для этих операций, работа с целым отношением как с одним операндом.

8. Физическая независимость – прикладные программы и утилиты для работы с данными на логическом уровне не должны меняться при изменении способов хранения данных.

9. Логическая независимость – прикладные программы не должны меняться при внесении в базовые таблицы изменений, которые теоретически позволяют старые данные.

10. Независимость условий целостности – условия целостности должны хранится в БД, а не в самой программе.

11. Прикладная СУБД не должна зависеть от потребностей конкретного клиента.

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