Пособие 988
.pdf
СОДЕРЖАНИЕ
ПРЕДИСЛОВИЕ ………………………………………….. 4
1.БАЗЫ ДАННЫХ ……………………………………….. 5
1.1.Понятие баз данных и систем управления ими … 5
1.2.Понятие первичного ключа ……………………… 6
2.ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ ………………... 8
2.1.Нормализация баз данных ………………………. 9
2.2.Реляционные отношения между таблицами БД ……………………………………. 10
2.3.Ссылочная целостность и каскадные изменения …………………………………………12
2.4.Индексы и методы доступа к данным …………. 16
2.5.Типы таблиц БД …………………………………. 18
3.ПРИМЕР СОЗДАНИЯ БАЗЫ ДАННЫХ МТС ……... 19
3.1.Основные объекты Access ……………………….19
3.1.1Таблицы ……………………………………….. 19
3.1.2.Формы ……………………………………….… 21
3.1.3.Запросы ………………………………………… 21
3.1.4.Отчеты …………………………………………. 23
3.2.Постановка задачи ………………………………..23
3.3.Структура БД Access ……………………………..24
3.4.Порядок выполнения работы …………………….24
4.ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ О СОЗДАНИИ ФОРМ И ЗАПРОСОВ …………………………………61
4.1.Расчет итоговых полей в запросе ………………..61
4.2.Добавление таблицы в запрос ………………….. 63
4.3.Создание табличной формы без помощи мастера …………………………………………… 65
4.4.Создание формы с помощью мастера …………. 68
4.5.Создание формы с подчиненной формой ……… 71
5.ЗАДАНИЯ ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ .. 76
ЛИТЕРАТУРА …………………………………………… 78
3
ПРЕДИСЛОВИЕ
Пособие подготовлено с целью заполнения необеспеченности учебной литературой по базам данных.
В первых двух частях пособия кратко изложены основные принципы проектирования баз данных, в третьей – пример создания базы данных средствами Access.
Четвертая часть пособия не является обязательной и содержит расширенные сведения о возможностях Access по созданию форм, запросов и отчетов.
Для работы с СУБД Access необходимо владение основными средствами Windows, которые излагаются в рамках курса «Информатика». Как и в других приложениях Windows, в Access для выполнения одних и тех же действий применяются различные средства – команды главного меню, кнопки на панелях инструментов, команды в ниспадающих или контекстных меню, а также быстрые клавиши. В пособии описывается ограниченный набор таких средств – по мнению авторов наиболее простой.
4
1. БАЗЫ ДАННЫХ
1.1.Понятие баз данных и систем управления ими
Под базой данных (БД) понимают хранилище структурированных данных, при этом данные должны быть непротиворечивы,
минимально избыточны и целостны.
Обычно БД создается для хранения и доступа к данным, содержащим сведения о некоторой предметной области, то есть некоторой области человеческой деятельности или области реального мира. Всякая БД должна представлять собой систему данных о предметной области. БД, относящиеся к одной и той же предметной области, в различных случаях содержат более или менее детализированную информацию о ней. Степень детализации определяется рядом факторов, прежде всего целью использования информации из базы данных и сложностью производственных (деловых) процессов, существующих в пределах предметной области в конкретных условиях.
С понятием базы данных тесно связано понятие системы управления базой данных (СУБД). Это комплекс программных средств, предназначенных для создания структуры новой базы, наполнения ее содержимым, редактирования содержимого и визуализации информации. Под визуализацией информации понимается отбор отображаемых данных в соответствии с заданным критерием, их упорядочение, оформление и последующая выдача на устройство вывода или передача по каналам связи.
Первые СУБД появились в середине шестидесятых годов.
Различают иерархические, сетевые и реляционные модели баз дан-
ных и соответствующие им системы управления базами данных, причем последние в настоящее время явно лидируют на рынке.
В реляционных базах данных данные хранятся в таблицах, строки и столбцы которых называются записями и полями соответственно. Записи соответствуют объекту, событию или явлению, а поля – атрибутам (признакам, характеристикам, параметрам) объекта, события или явления.
5
1. БАЗЫ ДАННЫХ
Например, таблица Регистрация междугородных перегово-
ров (табл. 1.1) может содержать следующие сведения:
–код города
–номер телефона
–дата разговора
–продолжительность разговора
–стоимость разговора.
|
|
|
|
|
Таблица 1.1 |
|
Регистрация междугородных переговоров |
|
|||
|
|
|
|
|
|
Номер |
Дата |
Код |
Длительность |
|
Стоимость |
телефона |
разговора |
города |
разговора |
|
разговора |
273-33-14 |
3/17/99 |
820 |
10 |
|
12,10 |
444-89-76 |
3/17/99 |
820 |
5 |
|
6,05 |
444-89-76 |
3/18/99 |
336 |
30 |
|
57,90 |
273-33-14 |
3/18/99 |
862 |
6 |
|
11,58 |
555-90-87 |
3/18/99 |
413 |
7 |
|
22,89 |
273-33-14 |
3/19/99 |
862 |
3 |
|
5,79 |
Записи о междугородных разговорах записываются в хронологическом порядке, каждая строка имеет одинаковую структуру и состоит из пяти столбцов, в которых могут содержаться различные данные – числа, символы, даты, время и т. д.
1.2.Понятие первичного ключа
Вкаждой таблице БД может существовать первичный ключ. Под первичным ключом понимают поле или набор полей, однозначно идентифицирующий запись. Значение первичного ключа в таблице БД должно быть уникальным, то есть в таблице не должно существовать двух или более записей с одинаковым значением первичного ключа. Первичный ключ должен быть минимально достаточным, т. е. в нем не должно быть полей, удаление которых из первичного ключа не отразится на его уникальности.
Вкачестве первичного ключа может использоваться номер телефона (см. табл. 1.2), поскольку один и тот же номер не может принадлежать разным абонентам, проживающим по различным адресам.
6
1.1. Понятие баз данных и систем управления ими
Таблица 1.2
Справочник абонентов МТС
Номер |
Фамилия И.О. |
Адрес |
|
телефона |
|||
|
|
||
111-99-98 |
Смирнов А.Е. |
Нефтяников, 14-4 |
|
273-33-14 |
Простаков И.Ф. |
Пехотинцев,1 |
|
444-89-76 |
Крылова О.И. |
Студенческая,45-8 |
|
555-90-87 |
Гаврилова И.А. |
Флотская,23-123 |
|
888-00-99 |
Бабушкина Л.П. |
Судостроительная,12 |
|
888-44-77 |
Котов Е.П. |
Судостроительная,6 |
Приведем другие примеры первичных ключей:
–номер и серия паспорта;
–номер двигателя;
–регистрационный номер банка, организации;
–идентификационный номер налогоплательщика.
Втех случаях, когда нельзя выбрать первичный ключ из имеющихся полей, следует добавить в таблицу семантически незначащее поле (т. е. не несущее иного смыслового содержания, кроме обеспечения уникальности записи). Например, в табл. 1.1 первичным ключом не могут быть поля:
–номер телефона – один и тот же абонент может звонить много раз;
–код города – в один и тот же город звонят различные абоненты;
–дата и время – в одно и тоже время могут быть звонки с разных телефонов в разные города.
Поэтому для обеспечения уникальности записей в таблицу должно быть добавлено поле с уникальными значениями, например номер заказа.
В большинстве современных СУБД уникальность первичного ключа отслеживается автоматически, кроме того, многие СУБД (в
частности ACCESS) требуют всегда определять первичный ключ для таблицы базы данных.
7
2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
Рассмотрим общие принципы проектирования реляционных БД. При проектировании структуры новой БД определяют сущность объектов и явлений предметной области, которые должны найти свое отражение в базе данных.
В конечном итоге анализ предметной области должен привести к созданию эскиза БД первого порядка. Как правило, каждой сущности в БД соответствует таблица. Затем в эскизе второго порядка для каждой таблицы БД приводится список полей записи.
Несмотря на существование методик анализа предметных областей, построения эскизов БД, необходимо отметить следующее:
–процесс определения окончательной структуры БД является циклическим, то есть на разных этапах проектирования – начиная от эскиза структуры БД и заканчивая опытной или даже промышленной эксплуатацией готовых программных систем - приходится возвращаться к структуре БД и вносить в нее изменения;
–в процессе моделирования предметной области участвуют такие субъективные факторы, как здравый смысл разработчика, его ин-
туиция, привычки, личностное восприятие проблемы, стереотипы мышления и т. д.
Поэтому различные разработчики наверняка предложат различные проекты структуры одной и той же БД, хотя в узловых моментах, например, в определении большей части сущностей и связей между ними, эти проекты должны быть похожи. Следовательно, с одной стороны, процесс проектирования структур БД является процессом творческим, неоднозначным, с другой стороны, узловые его моменты могут быть формализованы.
Одной из таких формализаций является требование, согласно которому реляционная база данных должна быть нормализована.
8
2.1. Проектирование баз данных
2.1. Нормализация баз данных
Существует несколько нормальных форм, цель которых – устранение избыточности данных. При практической разработке баз данных важны первые три – первая, вторая и третья нормальные формы.
Первая нормальная форма (1НФ) требует, чтобы каждое поле таблицы БД было неделимым и не содержало повторяющихся групп.
Неделимость поля означает, что значение поля не должно делиться на более мелкие значения. Например, если в поле адрес содержится название улицы и номер дома, требование неделимости не соблюдается и необходимо из данного поля выделить название улицы и номер дома в отдельные поля.
Вторая нормальная форма (2НФ) требует, чтобы все поля таблицы однозначно зависели от первичного ключа, т. е. чтобы первичный ключ однозначно определял запись и был минимально достаточным (см. подраздел 1.2).
Третья нормальная форма (3НФ) требует, чтобы значение любого поля, не входящего в первичный ключ, не зависело от значения другого поля, также не входящего в первичный ключ.
Например, в табл. 1.1 поле Стоимость разговора зависит от полей Длительность разговора и Код города и может вычисляться как значение поля Длительность разговора умноженное на стоимость одной минуты разговора с городом, соответствующим коду из поля Код города. Поэтому для устранения избыточной информации доба-
вим в базу данных таблицу Справочник кодов и тарифов
(табл. 2.1) и исключим из табл. 1.1 поле Стоимость разговора.
9
2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
Таблица 2.1
Справочник кодов и тарифов
Код города |
Стоимость минуты |
336 |
1,93 |
391 |
2,66 |
413 |
3,27 |
416 |
3,27 |
812 |
1,58 |
820 |
1,21 |
831 |
1,21 |
Нормализация баз данных призвана устранить в них избыточную информацию, и как видно из приведенного выше примера, таблицы нормализованной БД содержат только один элемент избыточных данных – поля связи (см. подраздел 2.2), присутствующие одновременно в двух таблицах.
Однако полностью нормализованные БД имеют и недостатки, прежде всего практического характера. Во-первых, БД в больших системах могут содержать сотни связанных между собой таблиц, что уменьшает целостное восприятие базы данных как системы взаимосвязанных данных. Во-вторых, при выполнении запросов поиск нужных записей может быть значительно замедлен из-за необходимости обращения сразу к нескольким связанным таблицам, особенно когда одна из таблиц имеет большой объем. Поэтому при работе с данными большого объема следует искать компромисс между требованиями нормализации и необходимостью улучшения быстродействия системы.
2.2.Реляционные отношения между таблицами БД
Между двумя или более таблицами базы данных могут существовать реляционные отношения, или связи. Реляционные отношения определяют, что для каждой записи главной таблицы (называемой еще родительской) может существовать одна или несколько записей в подчиненной (дочерней) таблице.
Существует три разновидности связей между таблицами:
один-ко-многим, один-к-одному и многие-ко-многим.
10
2.2. Реляционные отношения между таблицами БД
Отношение один-ко-многим
Отношение один-ко-многим является самым распространенным для реляционных баз данных и имеет место, когда одной записи родительской таблицы может соответствовать несколько записей в дочерней таблице.
Различают две разновидности связи один-ко-многим. В первом случае выдвигается жесткое требование, согласно которому всякой записи в родительской таблице должны соответствовать записи в дочерней таблице. Во втором случае подобное требование не носит жесткого характера и подразумевается, что некоторые записи в родительской таблице могут не иметь связанных с ними записей в дочерней таблице.
Например, одной записи из родительской таблицы Справочник абонентов МТС может соответствовать несколько записей в дочерней таблице Регистрация междугородных переговоров, но не для каждой записи в родительской таблице должна быть запись в дочерней (рис. 2.1). Это означает, что для каждого звонка, зареги-
стрированного в таблице Регистрация междугородных перегово-
ров, должен существовать номер телефона в таблице Справочник абонентов МТС, но не для каждого номера телефона из таблицы
Справочник абонентов МТС должна быть запись в таблице Регистрация междугородных переговоров.
Таблица Справочник абонен- |
Таблица |
Регистрация |
междуго- |
|||||
тов МТС – родительская |
родных переговоров – дочерняя |
|||||||
Номер |
Фамилия И.О. |
|
Номер |
|
Дата |
|
Ми |
Код |
телефона |
|
|
телефона |
|
|
|
ну- |
го- |
|
|
|
|
|
|
|
ты |
рода |
111-99-98 |
Смирнов А.Е. |
|
273-33-14 |
|
3/17/99 |
|
10 |
820 |
273-33-14 |
Простаков |
|
444-89-76 |
|
3/17/99 |
|
5 |
820 |
|
|
|
|
|
|
|
|
|
444-89-76 |
Крылова О.И. |
444-89-76 |
|
3/18/99 |
|
30 |
336 |
|
555-90-87 |
Гаврилова И.А. |
|
273-33-14 |
|
3/18/99 |
|
6 |
862 |
|
|
|
555-90-87 |
|
3/18/99 |
|
7 |
413 |
Рис. 2.1. Связь один-ко-многим
Связь один-ко-многим иногда называют связью многие-к- одному. В этом случае подразумевается, что мы смотрим на роди-
11
2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
тельскую таблицу со стороны дочерней. И в том и в другом случае сущность связи между таблицами остается неизменной.
Отношение один-к-одному
Связь один-к-одному имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице. Данное отношение встречается много реже, чем отношение один-ко- многим. Его используют, если не хотят, чтобы таблица БД содержала слишком много полей.
Использование связи один-к-одному приводит к тому, что для чтения связанной информации в нескольких таблицах приходится производить несколько операций чтения вместо одной, когда данные хранятся в одной таблице. Кроме того, базы данных, в состав которых входят таблицы со связью один-к-одному, не могут считаться до конца нормализованными.
Отношение многие-ко-многим
Отношение многие-ко-многим имеет место, когда:
–записи в родительской таблице может соответствовать больше одной записи в дочерней таблице:
–записи в дочерней таблице может соответствовать больше одной записи в родительской таблице.
Многие СУБД не поддерживают связь многие-ко-многим на уровне индексов и ссылочной целостности (см. подраздел 2.3), хотя и позволяют реализовывать ее добавлением вспомогательной таблицы, имеющей табличные отношения один-ко-многим.
2.3. Ссылочная целостность и каскадные изменения
Рассмотрим наиболее часто встречающуюся в базах данных связь один-ко-многим (рис. 2.2).
12