Отчёты отличаются от прочих объектов Access тем, что предназначены только для вывода данных на печатающее устройство, но не на экран. В них приняты специальные меры для группировки выходных данных и для вывода специальных элементов оформления, характерных для печатных документов.
Отчеты во многом похожи на формы и страницы доступа к данным, но имеют иное функциональное назначение — они служат для форматированного вывода данных на печатающие устройства и, соответственно, при этом должны учитывать параметры принтера и параметры используемой бумаги.
Здесь существуют средства ручного, автоматического и автоматизированного проектирования. Структура готового отчёта отличается от структуры формы только увеличенным количеством разделов. Кроме разделов заголовка, примечания и данных, отчёт может содержать разделы верхнего и нижнего колонтитулов. Если отчёт занимает более одной страницы, эти разделы необходимы для печати служебной информации, например номеров страниц.
Чем больше страниц занимает отчёт, тем важнее роль данных, выводимых на печать через эти разделы. Если для каких-то полей отчёта применена группировка, количество разделов отчёта увеличивается, поскольку оформление заголовков групп выполняется в отдельных разделах.
Структуру отчёта можно рассмотреть и отредактировать в режиме Конструктора. Она имеет следующие разделы:
· Область заголовка;
· Область данных;
· Область примечания;
· Область верхнего и нижнего колонтитулов (для печати номеров страниц и полного количества страниц).
Существуют два вида автоотчётов:
1. Автоотчёт в столбец и
2. Ленточный Автоотчёт
Этапы проектирования баз данных:
1. Системный анализ предметной области
2. Инфологическое проектирование
3. Выбор СУБД
4. Датологическое проектирование
5. Физическое проектирование
I Системный анализ предметной области
На первом этапе проектирования баз данных рассматриваются цели и задачи с помощью которой они будут решатся. Анализируются информационные потребности будущих пользователей баз данных. Рассматриваются формы входных и выходных потоков, которые будут составлять основу баз данных. Затем уточняются алгоритмы и процедуры обработки данных хранимой в базе данных. Формируются требования, которым должна удовлетворять проектируемая база данных и определяется примерный список объектов предметной области, свойства которых будут использоваться при разработке базы данных.
II Инфологическое проектирование
На второй стадии проектирования выполняется моделирование данных. Моделирование данных – это процесс создания логической структуры данных.
Существует два подхода к моделированию данных:
1. Модель «Сущность-связь»
2. Семантическая объектная модель
Эти модели представляют собой языки для описания структуры данных и их связей в представлениях пользователей. Моделирование данных, подобно блок-схемам, отражают логику программы.
III Выбор СУБД
При выборе СУБД руководствуются следующими соображениями:
- аппаратное обеспечение, на котором в дальнейшем будет работать проектируемая база данных;
- системное программное обеспечение, с которым будет в последствии работать проектируемая база данных и соответствующее ей приложения;
- методология и подходы, к программированию реализованные в той или иной СУБД;
- модель данных, которая встроена в конкретную СУБД;
Выбор СУБД полностью определяется на II этапе построения базы данных, т. к. оно зависит от той модели данных, которая встроена в выбранную СУБД.
IV Датологическое проектирование
После того, как выбор СУБД завершён, необходимо приступить к проектированию датологической модели базы данных. При формировании датологической схемы, каждая из определённых в концептуальной схеме сущностей отображается в таблицу, которая является одним отношением. При этом следует учитывать ограничения на размер таблиц, которые накладывает конкретная СУБД.
V Физическое проектирование
Этап физического проектирования заключается в увязке логической структуры БД и физической среды хранения с целью наиболее эффективного размещения данных, т.е. отображении логической структуры БД в структуру хранения. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам "физической" БД. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (DDL). Принятые на этом этапе решения оказывают определяющее влияние на производительность системы.
Этапы развития БД:
1. БД на больших эвм:
Все СУБД базируются на мощных мультипрограммных ОС, поэтому в основном поддерживается работа с централизованно БД в режиме распределенного доступа. функции управления распределением ресурсов в основном осуществляются ОС. поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным. значительная роль отводится администрированию данных. Проводятся серьезные работы по обоснованию и формализации модели данных( System R). Проводятся теоретические работы по оптимизации запросов и управлению распределенным доступом к БД, было введено понятие транзакций. появляются первые языки высокого уровня для работы с реляционной моделью данных, однако отсутствуют стандарты для этих языков.
2. Эпоха ПК:
Все субд были рассчитаны на создание бд с монопольным доступом. Большинство СУБД имели удобный и развитый пользовательский интерфейс. в большинстве существовал интерактивный режим работы с БД, как в рамках описания БД, так и в рамках проектирования запросов. Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели( только внешний табличный вид структуры данных). при наличии высокоуровневых языков манипулирования данными типа реляционной алгебры, в настольных СУБД поддерживались низкоуровневые языки манипулирования данными, на уровне строк и таблиц. в настольных субд отсутствовали средства поддержки ссылочной и структурной целостности БД. Эти функции должны были выполнять приложения, однако, скудность средств разработки приложений никогда не позволяла это сделать, и в этом случае функции выполнялись пользователем. Наличие монопольного режима работы фактически привело к рождению функций администрирования БД. В связи с этим отсутствовали инструментальные средства администрирования БД. Сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. (D Base, Fox Pro, Paradox, Cleepper).
3. Распределенные БД:
Практически все современные СУБД обеспечивают поддержку полной реляционной модели(структурная целостность(допустимыми являются только данные, представленные в виде отношения реляционной модели), языковой целостности, ссылочной целостности( контроль за соблюдением ссылочной целостности, и гарантия невозможности со стороны СУБД нарушить ограничения). Большинство современных СУБД рассчитаны на многоплатформенную архитектуру. Необходимость поддержки многопользовательской работы с БД. возможность децентрализованного хранения данных потребовалось развитие средств администрирования с реализацией общей концепции средств защиты данных. Для того, чтобы не потерять клиентов, которые ранее работали на настольных СУБД, практически все современные СУБД имеют средства подключения клиентских приложений, разработанных с использованием настольных СУБД и средств экспорта данных из форматов настольных СУБД 2 этапа развития. Разработан ряд стандартов, в рамках языков описания и манипулирования данными технологии по обмену данными между различными данными, к которым можно отнести протокол ODBC, предложенной фирмой Microsoft. К этому этапу можно отнести начало работ, связанных с концепцией объектно-ориентированных БД. Oracle7.3, 8.4., System 10-11, informix, DB2.