Министерство образования и науки российской федерации
Рыбинская государственная авиационная технологическая академия имени П.А. Соловьева
Кафедра математического и программного обеспечения электронно-вычислительных систем
ЛАБОРАТОРНЫЙ ПРАКТИКУМ
по курсу: «Информационное обеспечение, базы данных»
Составил: д.т.н. В.А. Камакин
Рыбинск
2010
Содержание
1.1.Лабораторная работа №1. Выделение базовой информации из предметных областей. Формализация информации 7
1.2.Цель работы 7
1.3.Организация баз данных 7
1.4.Представление данных 9
1.5.Практическое задание 10
1.6.Указания по выполнению работы 10
1.7.Контрольные вопросы 11
1.8.Лабораторная работа №2. Начальные данные о реляционной СУБД. Основы работы с СУБД Access 12
1.9.Цель работы 12
1.10.Программное обеспечение 12
1.11.Теоретические сведения 12
1.11.1.Реляционная модель данных 12
1.11.2.Принципы построения реляционной базы данных 13
1.11.3.Правила Кодда 17
1.11.4.СУБД Microsoft Access и ее реляционная база данных 18
1.11.5.Объекты Access 20
1.12.Размещение базы данных 21
1.13.Интерфейс Access 23
1.14.Диалоговые средства конструирования объектов 24
1.14.1.Мастера баз данных 24
1.14.2.Средства программирования 25
1.14.3.Многопользовательская база данных Access 26
1.14.4.Репликация баз данных 27
1.15.Практическое задание 28
1.16.Указания по выполнению работы 28
1.17.Контрольные вопросы 28
1.18.Лабораторная работа №3. Cоздание базы данных в среде ACCESS 30
1.19.Цель работы 30
1.20.Программное обеспечение 30
1.21.Начало работы в Microsoft Access. Запуск Access 30
1.21.1.Окно Access 30
1.21.2.Строка заголовка окна 30
1.21.3.Строка меню 31
1.21.4.Панели инструментов 31
1.21.5.Строка состояния 32
1.21.6.Диалоговые окна 32
1.22.Окно базы данных 33
1.23.Создание новой базы данных 34
1.24.Создание файла базы данных Access 35
1.25.Окно файла новой базы данных 36
1.26.Окно базы данных 36
1.27.Создание таблицы базы данных 37
1.27.1.Определение структуры новой таблицы в режиме конструктора 37
1.27.2.Определение полей таблицы 37
1.27.3.Имена полей и типы данных 38
1.27.4.Общие свойства поля 39
1.27.5.Тип элемента управления 42
1.27.6.Определение первичного ключа 43
1.28.Сохранение таблицы 43
1.29.Создание новой таблицы в режиме таблицы 45
1.30.Создание таблицы с помощью мастера таблиц 48
1.31. Непосредственный ввод данных в таблицу 48
1.32.Макет таблицы 49
1.33.Лабораторная работа №4. Cоздание схемы данных в среде ACCESS 52
1.34.Цель работы 52
1.35.Программное обеспечение 52
1.36.Ввод логически связанных записей 52
1.37.Схема данных в ACCESS 52
1.38.Взаимосвязи таблиц 53
1.39.Одно-многозначные (1:М) или одно-однозначные (1:1) связи 53
1.40.Обеспечение целостности данных 54
1.41.Каскадное обновление и удаление связанных записей 55
1.42.Создание схемы данных 55
1.42.1.Включение таблиц в схему данных 56
1.42.2.Создание связей между таблицами 56
1.42.3.Задание параметров целостности 56
1.43.Изменение схемы данных 58
1.44.Ввод и корректировка данных во взаимосвязанных таблицах 60
1.44.1.Отображение записей подчиненных таблиц в главной 61
1.45.Модификация структуры базы данных 64
1.45.1.Изменение структуры таблиц 64
1.45.1.1.Изменение полей, которые не являются ключами или полями связи 64
1.45.1.2.Изменение или удаление ключевого поля 64
1.46.Лабораторная работа №5. Создание форм для однотабличных и многотабличных структур данных в среде Access 66
1.47.Цель работы 66
1.48.Программное обеспечение 66
1.49.Форма - диалоговый графический интерфейс пользователя для работы с базой данных 66
1.50.Технология загрузки базы данных с использованием форм 67
1.51.Последовательность загрузки таблиц базы данных 67
1.52.Этапы загрузки базы данных и проектирования форм 68
1.53.Основы создания однотабличных форм 69
1.53.1.Конструирование формы 69
1.53.2.Области и элементы формы в режиме конструктора 69
1.54.Панели инструментов конструктора форм и форматирования 70
1.54.1.Настройка панели инструментов 72
1.54.2.Панель элементов 73
1.54.3.Переход в режим конструктора форм 74
1.54.4.Мастера создания формы 74
1.55.Основы создания многотабличных форм 76
1.55.1.Создание многотабличной формы с помощью мастера 76
1.55.2.Способы построения многотабличной формы 76
1.55.3.Многотабличная форма без подчиненных и связанных форм 77
1.55.4.Многотабличная форма на основе запроса 77
1.55.5.Создание формы мастером, выбор таблиц и полей 77
1.55.6.Выбор варианта создания многотабличной формы, отображение данных главной и подчиненной таблиц 78
1.55.7.Завершение создания формы мастером 79
1.55.8.Доработка формы в режиме конструктора 79
1.55.9.Создание и редактирование многотабличной формы в режиме конструктора 79
1.56.Создание новой формы конструктором 80
1.56.1.Включение полей в новую форму 80
1.56.2.Добавление подчиненной формы и ее редактирование 81
1.57.Вычисления в форме 82
1.57.1.Вычисления в каждой записи формы 82
1.57.2.Вычисление итоговых значений 83
1.58.Ограничения доступа к данным через форму 83
1.58.1.Защита данных поля от изменений 83
1.58.2.Защита данных подчиненной формы от изменений 84
1.59.Лабораторная работа №6. Создание запросов в среде Access 86
1.60.Цель работы 86
1.61.Программное обеспечение 86
1.62.Назначение и виды запросов 86
1.63.Создание запроса 87
1.64.Окно запроса 88
1.65.Схема данных запроса 88
1.66.Бланк запроса QBE 88
1.67.Поля бланка запроса 89
1.68.Модификация запроса 89
1.69.Условия отбора записей 90
1.70.Построитель выражений 91
1.71.Вычисляемые поля 92
1.72.Арифметические выражения 92
1.73.Встроенные функции 92
1.74.Присвоение пользовательских имен вычисляемым полям 93
1.75.Параметры запроса 93
1.75.1.Определение параметра запроса по значению поля 93
1.75.2.Определение нескольких параметров запроса 93
1.75.3.Параметр запроса для ввода значения операнда выражения 94
1.76.Корректировка данных средствами запроса 94
1.76.1.Запрос на обновление 94
1.76.2.Запрос на добавление 95
1.76.3.Запрос на удаление 96
1.77.Мастера создания запросов 97
1.78.Мастера запросов на выборку 98
1.78.1.Простой запрос 98
1.78.2.Запрос для поиска повторяющихся записей 98
1.78.3.Запрос для поиска записей, не имеющих подчиненных 98
1.78.4.Мастер перекрестных запросов 98
1.79.Лабораторная работа №7. Создание отчетов в среде Access 100
1.80.Цель работы 100
1.81.Программное обеспечение 100
1.82.Создание отчетов 100
1.83.Конструирование отчетов 100
1.83.1.Окно конструктора отчета 101
1.83.1.1.Разделы отчета 101
1.83.1.2.Элементы разделов отчета 101
1.83.1.3.Панель инструментов конструктора отчетов 103
1.83.2.Создание отчета 103
1.83.2.1.Создание отчета в режиме конструктора 103
1.83.2.2.Группировка и сортировка данных отчета 103
1.83.2.3.Размещение полей из таблиц 103
1.83.2.4.Включение вычисляемого поля в отчет 104
1.83.2.5.Добавление текущей даты и номера страницы 104
1.83.2.6.Завершение оформления отчета 105
1.84.Просмотр и печать отчета 105
1.84.1.Просмотр отчета 105
1.84.2.Печать отчета 106
1.85.Литература 107
Лабораторная работа №1. Выделение базовой информации из предметных областей. Формализация информации
Цель работы
Усвоение методов определения предметных областей и формализации информации.
Организация баз данных
Любые объекты в окружающем мире характеризуются совокупностью знаний о них. Так, например, мы знаем о человеке, как его зовут, когда он родился, сколько у него детей, и кто его дети, кличка любимой собаки, семейное положение, болезни, образование, привычки, домашний адрес, место работы, черты характера и т.п. Когда в качестве объекта выступает какая-либо организация или технологический процесс, то им соответствует свой специфический и тоже бесконечный набор атрибутов знания (информации). Этот набор знаний постоянно увеличивается, он не связан с какой-либо областью их приложения, а содержит все то, что известно об объекте – предмете исследования. Такая полная совокупность знаний об объекте окружающего мира и составляет предметную область объекта. Однако, для обработки информации об объекте полный охват его предметной области не только не требуется, но даже и вреден. Более того, даже не просто вреден, а невозможен. Поскольку предметная область содержит бесконечное множество знаний об объекте, то их определение, фиксация и обработка потребует бесконечного объема ресурсов: бумаги, чернил, памяти машины, времени работы оператора и т.п. При организации информационного обеспечения любого процесса необходимо, прежде всего, выделить из предметной области необходимый минимум знаний. Таких знаний должно быть как можно меньше, ибо каждый новый атрибут – это дополнительные затраты ресурсов, нарастающие при этом отнюдь не линейно. С другой стороны, этих знаний должно быть достаточно, для того чтобы удовлетворять информационные потребности процесса. Таким образом из предметной области необходимо изъять:
знания не используемые для информационного обеспечения конкретного процесса (например, информация о любимой собаке работника);
знания, которые могут быть получены путем логических либо математических операций из других (например, если есть информация о дате рождения человека, то нет необходимости выделять его возраст, поскольку он может быть получен исходя из текущей даты и даты рождения).
повторяющиеся знания.
Оставшийся минимум атрибутов предметной области, помещенный на определенный носитель называется базой данных. Вид базы данных определяется выбранным исходя из возможностей организации и спецификой объекта носителем. Наиболее общее подразделение баз данных на ручные и машинные.
Ручная база данных – это база данных, выполненная без применения средств вычислительной техники, организованная и обрабатываемая целиком и полностью человеком. Домашняя фонотека – типичный пример ручной базы данных, хотя информация представлена на электронных носителях – магнитных кассетах.
Машинная (автоматизированная) база данных – система, в которой организация хранения и обработки информации производится с использованием компьютеров. Особенно эффективными показали себя такие базы данных для хранения и обработки текстовой и числовой информации. Современные системы управления базами данных (СУБД) позволяют хранить информацию в любом формате, поддерживаемом приложениями операционной системы, и обрабатывать ее средствами этих приложений. В машинной базе данных, например, можно хранить информацию о структуре и содержании стандартов ИСО 9000, фотографии работников организации, технологическую и конструкторскую документацию, разработанную средствами любых систем автоматического проектирования, программы для станков с ЧПУ, рекламные видеоролики об организации и т.д.
Одной из проблем, не решенных на сегодняшний день, является передача информации между ручными и машинными базами. Единственным способом такого взаимодействия является схема машинная (автоматизированная) база данных – человек – ручная база данных. В результате информация обрабатывается иногда даже хуже, чем при использовании любой из них в отдельности. Решение проблемы многие видят в постепенном отмирании ручных баз данных и полном переходе на машинные.
Машинные базы данных действительно несоизмеримо более эффективно удовлетворяют информационные потребности, однако для их использования необходимо соблюдать определенные правила взаимодействия с искусственным интеллектом. Значительная часть этих правил связана с тем, чтобы обеспечить «понимание» компьютером человека и наоборот. Русский человек испытывает определенные затруднения в общении с японцем. Но ведь и японцы и русские относятся к одному и тому же виду Homo Sapiens. И японец и русский в принципе мыслят одинаково – символьными образами – «чанками». Компьютер же по своей сути существо чуждое человеку – он мыслит кодами. Процесс его «мышления» заключается в формальном выполнении фиксированного набора команд, представленных средствами двоичной логики. Само содержание таких команд крайне сложно для понимания человеком, особенно для того, кто связан профессионально с вычислительной техникой. Поэтому необходимо иметь средства обеспечивающие «перевод» запросов с человеческого языка на машинный, а результатов их обработки – обратно на язык понятный оператору (пусть даже и английский). Одним из аспектов такого перевода является представление предметных областей на машинных носителях – перевод информации, представленной чанками – в двоичный код.
Представление данных
Работы по созданию универсальных средств представления знаний ведутся едва ли не сначала 60-х годов. В результате появились, так называемые, модели данных, представляющие собой упрощенные способы отображения знаний об объекте и использующие определенные принципы организации данных. На базе таких моделей данных были разработаны программные системы обработки информации – системы управления базами данных или СУБД. Интересная деталь: практически все известные на сегодняшний день модели данных (кроме объектных) были разработаны почти одновременно (с 1967 по 1971 годы). Однако на том или ином историческом этапе рынок СУБД захватывался одной максимум двумя моделями данных. На сегодняшний день имеются системы, реализующие все известные модели данных. Причем реляционная модель является самой универсальной, поскольку позволяет реализовывать любые схемы данных и структуры. На сегодняшний день известны следующие модели данных:
системы управления файлами;
иерархические модели данных;
сетевые модели данных;
реляционные модели данных;
постреляционные модели данных;
многомерные модели данных;
объектно-ориентированные модели данных.
Поиски решения проблемы представления знаний с целью их формализации и последующей обработки начали осуществляться задолго до создания автоматизированных систем управления базами данных. Информацию необходимо группировать, сортировать, преобразовывать. Для осуществления такой обработки традиционно осуществляется расчленение информации на совокупность характеристик – атрибутов. Например, информация о покупном изделии может включать в себя поставщика, стоимость, наличие на складе, в какое изделие входит и т.п. Все это атрибуты, позволяющие удовлетворять информационные запросы в рамках процесса управления поставщиками. Каждый конкретный информационный объект имеет уникальный набор значений атрибутов. Так, например, приведенный выше набор атрибутов для покупного изделия «Болт» может иметь следующие значения: поставщик – ЗАО «Галс», стоимость – 10 коп, наличие на складе – 100 кг, в какое изделие входит – ДТ–700. Такая организация хранения информации позволяет производить её эффективную обработку. Например, можно определить, какие ещё изделия поставляет ЗАО «Галс» или подсчитать стоимость всех покупных изделий, входящих в определенную продукцию. Такой подход к обработке информации посредством её расчленения на пары атрибут – значение имеет длительную историю, существенно превышающую возраст автоматизированных систем управления данными. Точная дата возникновения такого принципа неизвестна, но можно с уверенностью сказать, что он появился почти одновременно с языком и письменностью. Примечательно, что и в наш информационный век ничего более эффективного изобрести так не удалось. И хотя этот принцип наиболее адекватен для табличных моделей данных, тем не менее он является основой и для всех других, в том числе и объектно-ориентированных, которые вроде бы должны бы быть основаны не на расщеплении, а на рассмотрении объекта в совокупности его характеристик.
Практическое задание
Определить необходимый набор атрибутов для создания базы данных, обеспечивающей решение следующих задач.
Управление документацией.
Обслуживание пациентов поликлиники.
Регистрация автомототранспорта.
Прием студентов в учебное заведение.
Контроль качества продукции.
Изготовление детали (любой на выбор).
Управление кадрами.
Разработка домашней видеотеки.
Организация работы оптовой фирмы.
Разработка графика работы персонала предприятия.
Инвентаризация оборудования подразделения.
Управление измерительным оборудованием.
Указания по выполнению работы
Представленный набор атрибутов должен обеспечивать удовлетворение любого информационного запроса в рамках поставленной задачи.
Полученная база данных не должна содержать избыточной информации (кроме, возможно повторяющейся).
Результат оформить в виде таблицы:
Информационная задача: {привести задание}
-
№ пп
|
Название атрибута
|
Пример значения атрибута
|
Примечание
|
1,2,3,…
|
Имя атрибута
|
2 – 3 примера значения
|
Для удовлетворения каких информационных запросов он необходим (1 – 2 примера)
|
Контрольные вопросы
Понятие предметной области.
Понятие избыточных знаний.
Понятие базы данных.
Ручная и автоматизированная база данных.
Модели данных.
Определение атрибута.
Определение значения атрибута.
Лабораторная работа №2. Начальные данные о реляционной СУБД. Основы работы с СУБД Access
Цель работы
Изучение принципов организации хранения информации в реляционной СУБД. Основы работы с реляционной СУБД на примере СУБД Access.
Программное обеспечение
Для выполнения работы необходим MS Office 97. Рекомендуется MS Office 2000/XP
Теоретические сведения
Реляционная модель данных
Недостатки иерархической и сетевой моделей привели к появлению новой, реляционной модели данных, созданной Тэдом Коддом в 1970 году. Реляционная модель была попыткой упростить структуру базы данных. В ней отсутствовали явные указатели на предков и потомков, а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы.
К сожалению, практическое определение понятия «реляционная база данных» оказалось гораздо более расплывчатым, чем точное математическое определение, данное этому термину Коддом в 1970 году. В первых реляционных СУБД не были реализованы некоторые из ключевых частей модели Кодда, и этот пробел был восполнен только впоследствии. По мере роста популярности реляционной концепции реляционными стали называться многие базы данных, которые на деле таковыми не являлись.
В ответ на неправильное использование термина "реляционный" Кодд в 1985 году написал статью, где сформулировал 12 правил, которым должна удовлетворять любая база данных, претендующая на звание реляционной. С тех пор двенадцать правил Кодда считаются определением реляционной СУБД. Однако можно сформулировать и более простое определение:
Реляционной называется база данных, в которой все данные, доступные пользователю, организованны в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами.
Приведенное определение не оставляет места встроенным указателям, имеющимся в иерархических и сетевых СУБД. Несмотря на это, реляционная СУБД также способна реализовать отношения предок/потомок, однако эти отношения представлены исключительно значениями данных, содержащихся в таблицах.
Принципы построения реляционной базы данных
В
Офисы
|
|
|
Офис №
|
Город
|
Рук.
|
Кол. служащих
|
Продажи
|
22
|
Москва
|
108
|
20
|
9,086,042.00
|
11
|
Ярославль
|
106
|
8
|
4,692,000.00
|
12
|
Кострома
|
104
|
9
|
1,739,000.00
|
13
|
Череповец
|
105
|
15
|
5,735,157.00
|
21
|
Рыбинск
|
107
|
5
|
1,835,915.00
|
Город, в котором расположен офис
Идентификатор служащего, управляющего офисом
Объём продаж офиса с начала года
Данные об офисе в Ярославле
 
Данные об офисе в Рыбинске
Рис. 2.1. Структура реляционной таблицы
реляционной базе данных информация организована в виде таблиц, разделённых на строки и столбцы, на пересечении которых содержатся значения данных. У каждой таблицы имеется уникальное имя, описывающее её содержимое. Более наглядно структуру таблицы иллюстрирует рис. 2.1, на котором изображена таблица OFFICES. Каждая горизонтальная строка этой таблицы представляет отдельную физическую сущность – один офис. Пять строк таблицы вместе представляют все пять офисов компании. Все данные, содержащиеся в конкретной строке таблицы, относятся к офису, который описывается этой строкой.
Каждый вертикальный столбец таблицы «Офисы» представляет один элемент данных для каждого из офисов. Например, в столбце «Город» содержатся названия городов, в которых расположены офисы. В столбце «Продажи» содержатся объёмы продаж, обеспечиваемые офисами.
На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей ярославский офис, в столбце «Город» содержится значение «Ярославль». В столбце «Продажи» той же строки содержится значение 4,692,000.00, которое является объёмом продаж ярославского офиса с начала года.
Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Например, в столбце «Город» содержатся только слова, в столбце «Продажи» содержатся денежные суммы, а в столбце «Рук.» содержатся целые числа, представляющие идентификаторы служащих. Множество значений, которые могут содержаться в столбце, называется доменом этого столбца. Доменом столбца «Город» является множество названий городов. Доменом столбца «Продажи» является любая денежная сумма.
У каждого столбца в таблице есть своё имя, которое обычно служит заголовком столбца. Все столбцы в одной таблице должны иметь уникальные имена, однако разрешается присваивать одинаковые имена столбцам, расположенным в различных таблицах. На практике такие имена столбцов, как ИМЯ, АДРЕС, СТОИМОСТЬ, ПРОДАЖИ часто встречаются в различных таблицах одной базы данных.
Столбцы таблицы упорядочены слева направо, и их порядок определяется при создании таблицы. В любой таблице всегда есть как минимум один столбец. В стандарте ANSI/ISO не указывается максимально допустимое число столбцов в таблице, однако почти во всех коммерческих СУБД этот предел существует и обычно составляет примерно 255 столбцов.
В отличие от столбцов, строки таблицы не имеют определённого порядка. Это значит, что если последовательно выполнить два одинаковых запроса для отображения содержимого таблицы, нет гарантии, что оба раза строки будут перечислены в одном и том же порядке.
В таблице может содержаться любое количество строк. Вполне допустимо существование таблицы с нулевым количеством строк. Такая таблица называется пустой. Пустая таблица сохраняет структуру, определённую её столбцами, просто в ней не содержится данные. Стандарт ANSI/ISO не накладывает ограничений на количество строк в таблице, и во многих СУБД размер таблиц ограничен лишь свободным дисковым пространством компьютера. В других СУБД имеется максимальный предел, однако он весьма высок – около двух миллиардов строк, а иногда и больше.
Поскольку строки в реляционной таблице не упорядочены, нельзя выбрать строку по ее номеру в таблице. В таблице нет «первой», «последней» или «тринадцатой» строки. Тогда каким же образом можно указать в таблице конкретную строку, например строку для офиса, расположенного в Череповце?
В правильно построенной реляционной базе данных в каждой таблице есть один или несколько столбцов, значения в которых во всех строках разные. Этот столбец (столбцы) называется первичным ключом таблицы. Давайте вновь посмотрим на базу данных, показанную на рис.2.1. На первый взгляд, первичным ключом таблицы «Офисы» могут служить и столбец «Офис», и столбец «Город». Однако в случае, если компания будет расширяться и откроет в каком-либо городе второй офис, столбец «Город» больше не сможет выполнять роль первичного ключа. На практике в качестве первичных ключей таблиц обычно следует выбирать идентификаторы, такие как идентификатор офиса («Офис» в таблице «Офисы»).
Т
аблица «Товары», фрагмент которой показан на рис. 2.2, является примером таблицы, в которой первичный ключ представляет собой комбинацию столбцов. Такой первичный ключ называется составным. Столбец «Изг.» содержит идентификаторы производителей всех товаров, перечисленных в таблице, а столбец «Тип» содержит номера, присвоенные товарам производителями. Может показаться, что столбец «Тип» мог бы и один выполнять роль первичного ключа, однако ничто не мешает двум различным производителям присвоить своим изделиям одинаковые номера. Таким образом, в качестве первичного ключа таблицы «Товары» необходимо использовать комбинацию столбцов «Изг.» и «Тип». Для каждого из товаров, содержащихся в таблице, комбинация значений в этих столбцах будет уникальной.
Первичный ключ для каждой строки таблицы является уникальным, поэтому в таблице с первичным ключом нет двух совершенно одинаковых строк. Таблица, в которой все строки отличаются друг от друга, в математических терминах называется отношением. Именно этому термину реляционные базы данных и обязаны своим названием, поскольку в их основе лежат отношения (таблицы с отличающимися друг от друга строками).
Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности определить для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.
Одним из отличий реляционной модели от первых моделей представления данных было то, что в ней отсутствовали явные указатели, используемые для реализации отношений предок/потомок в иерархической модели данных. Однако вполне очевидно, что отношения предок/потомок существуют и в реляционных базах данных. Например, в приведенной выше базе данных каждый из служащих закреплен за конкретным офисом, поэтому ясно, что между строками таблицы «Подразделения» и таблицы «Сотрудники» существует отношение. Не приводит ли отсутствие явных указателей в реляционной модели к потере информации?
Как следует из рис.2.3, ответ на этот вопрос должен быть отрицательным. На рисунке изображено несколько строк из таблиц «Подразделения» и «Сотрудники». Обратим внимание на то, что в столбце «Подразделение» таблицы «Сотрудники» содержится идентификатор офиса, в котором работает служащий. Доменом этого столбца (множеством значений, которые могут в нем храниться) является множество идентификаторов офисов, содержащихся в столбце «Код» таблицы «Подразделения». То, в каком офисе работает инженер Шустров, можно узнать, определив значение столбца «Подразделение» в строке таблицы «Сотрудники» для Шустрова (число 2) и затем отыскав в таблице «Подразделения» строку с таким же значением в столбце «Код» (это для службы внутреннего аудита качества). Таким же образом, чтобы найти всех работников службы внутреннего аудита качества, следует запомнить значение столбца «Код» для нее (число 2), а потом просмотреть таблицу «Сотрудники» и найти все строки, в столбце «Подразделение» в которых содержится число 2 (это строки для Шустрова Е.М. и Стрелкова Г.А.).
Отношение предок/потомок, существующее между офисами и работающими в них людьми, в реляционной модели не потеряно; просто оно реализовано в виде одинаковых значений данных, хранящихся в двух таблицах, а не в виде явного указателя. Все отношения, существующие между таблицами реляционной базы данных, реализуются в таком виде.
Столбец одной таблицы, значения в котором совпадают со значениями столбца, являющегося первичным ключом другой таблицы, называется внешним ключом. На рис.2.3 столбец «Подразделение» представляет собой внешний ключ для таблицы «Подразделения». Значения, содержащиеся в этом столбце, представляют собой идентификаторы офисов. Эти значения соответствуют значениям в столбце «Код», который является первичным ключом таблицы «Подразделения». Совокупно первичный и внешний ключи создают между таблицами, в которых они содержатся, такое же отношение предок/потомок, как и в иерархической базе данных.
Внешний ключ, как и первичный ключ, тоже может представлять собой комбинацию столбцов. На практике внешний ключ всегда будет составным (состоящим из нескольких столбцов), если он ссылается на составной первичный ключ в другой таблице. Очевидно, что количество столбцов и их типы данных в первичном и внешнем ключах совпадают.
Если таблица связана с несколькими другими таблицами, она может иметь несколько внешних ключей. Отношения предок/потомок, созданные с помощью нескольких внешних, это те же самые отношения, что и в сетевой базе данных. Как показывает пример, реляционная модель данных обладает всеми возможностями сетевой модели по части выражения сложных отношений.
Внешние ключи являются неотъемлемой частью реляционной модели, поскольку реализуют отношения между таблицами базы данных. К сожалению, как и в случае с первичными ключами, поддержка внешних ключей отсутствовала в первых реляционных СУБД. Она была введена в системе DB2 Version 2 и теперь имеется во всех коммерческих СУБД.
Правила Кодда
В статье, опубликованной в журнале «Computer World», Тэд Кодд сформулировал двенадцать правил, которым должна соответствовать настоящая реляционная база данных. Двенадцать правил Кодда приведены ниже. Они являются полуофициальным определением понятия реляционная база данных. Перечисленные правила основаны на теоретической работе Кодда, посвященной реляционной модели данных.
Правило информации. Вся информация в базе данных должна быть предоставлена исключительно на логическом уровне и только одним способом - в виде значений, содержащихся в таблицах.
Правило гарантированного доступа. Логический доступ ко всем и каждому элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путём использования комбинации имени таблицы, первичного ключа и имени столбца.
Правило поддержки недействительных значений. В настоящей реляционной базе данных должна быть реализована поддержка недействительных значений, которые отличаются от строки символов нулевой длинны, строки пробельных символов, и от нуля или любого другого числа и используются для представления отсутствующих данных независимо от типа этих данных.
Правило динамического каталога, основанного на реляционной модели. Описание базы данных на логическом уровне должно быть представлено в том же виде, что и основные данные, чтобы пользователи, обладающие соответствующими правами, могли работать с ним с помощью того же реляционного языка, который они применяют для работы с основными данными.
Правило исчерпывающего подъязыка данных. Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем (например, режим вопросов и ответов). Однако должен существовать по крайней мере один язык, операторы которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает следующие элементы:
— определение данных;
— определение представлений;
— обработку данных (интерактивную и программную);
— условия целостности;
— идентификация прав доступа;
— границы транзакций (начало, завершение и отмена).
Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.
Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при добавлении, обновлении и удалении данных.
Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.
Правило независимости логических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при внесении в базовые таблицы любых изменений, которые теоретически позволяют сохранить нетронутыми содержащиеся в этих таблицах данные.
Правило независимости условий целостности. Должна существовать возможность определять условия целостности, специфические для конкретной реляционной базы данных, на подъязыке реляционной базы данных и хранить их в каталоге, а не в прикладной программе.
Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.
Правило единственности. Если в реляционной системе есть низкоуровневой язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности, выраженные на реляционном языке высокого уровня (обрабатывающем несколько записей за один раз).
СУБД Microsoft Access и ее реляционная база данных
СУБД Microsoft Access является системой управления реляционной базой данных, включающей все необходимые инструментальные средства для создания локальной базы данных, общей базы данных в локальной сети с файловым сервером или создания приложения пользователя, работающего с базой данных на SQL-сервере.
В качестве учебной системы она выбрана по следующим соображениям.
Во-первых, в Microsoft Access наиболее полно реализована концепция реляционных баз данных в том виде, в котором она была разработана Коддом.
Во-вторых, Microsoft Access является элементом Microsoft Office и, следовательно, его не надо специально приобретать.
В-третьих, Microsoft Access наиболее хорошо работает с другими приложениями Microsoft Office, а также другими форматами баз данных, например популярным до недавнего времени форматом DBase .dbf.
В-четвертых, в Access 2000 получили значительное развитие два технологических направления, составляющих основу корпоративных сетей:
Технология клиент/сервер, для реализации которой в Access включены средства создания проекта-приложения, работающего в качестве клиента баз данных SQL-сервера. Подключение к серверу реализуется с помощью нового интерфейса OLE DB без использования ядра баз данных Microsoft Jet. В Microsoft SQL Server 7.0 этот интерфейс является базовым. Благодаря этому Access становится универсальной основой для построения клиентских приложений, работающих с SQL-сервером.
Internet-технология, позволяющая эффективно распространять и получать доступ к разнородной информации в глобальных и корпоративных сетях. Эта технология обеспечивает унифицированный доступ к данным различных приложений в разнородных сетях. Для реализации Internet-технологии в Access включены новые интерактивные средства конструирования Web-страниц доступа к данным в базах Access и SQL-серверов. При этом Web-браузер используется как универсальный интерфейс для доступа и работы с информацией из внешней среды вне зависимости от аппаратно-программной платформы компьютера пользователя и компьютера — источника информации. Страницы могут использоваться подобно формам Access — для ввода и редактирования данных или подобно отчетам Access — для отображения иерархически сгруппированных записей.
К сожалению, система Access не лишена недостатков.
Во-первых, как и у других программных продуктов фирмы Microsoft наблюдаются ошибки в работе;
Во-вторых, Access не всегда корректно конвертирует файлы версии 97 года в формат Access 2000. Компилированные файлы (.mde) в принципе читаются только теми версиями, в которых они созданы.
В-третьих, Access достаточно тяжело работает для сопровождения распределенных баз данных.
Таким образом, для практического использования Access можно порекомендовать в качестве средства информационного обеспечения небольшой фирмы.
Access входит в состав Microsoft Office (в варианты Professional, Premium и Developer) и, как и другие компоненты Office , работает в среде Windows 95, Windows 98, 2000, XP или Windows NT Workstation 4.0 и выше.
Практическим минимумом, предъявляемым Access к персональному компьютеру, является Pentium 75 MHz и 16 Мб оперативной памяти при работе под Windows 95 или Windows 98 или 32 Мб при работе под Windows NT Workstation. При одновременном выполнении нескольких приложений Office необходимо дополнительно для каждого приложения по 4 Мб, а для Access, Outlook и FrontPage по 8 Мб, а для PhotoDraw - 16 Мб. При стандартной установке набора приложений: Word, Excel, Outlook, PowerPoint, Access, FrontPage требуется примерно 250 Мб на жестком диске. В зависимости от конфигурации приложений требования к объему жесткого диска изменятся. Рекомендуется монитор SVGA, возможно использование VGA. При установке приложений Office на локальном компьютере требуется дисковод CD-ROM.
Объекты Access
Access ориентирована на работу с объектами, к которым относятся таблицы базы данных, запросы, а также объекты приложений для работы с базой данных: формы, отчеты, страницы, макросы и модули.
Для типовых процессов обработки данных — просмотра, обновления, поиска по заданным критериям, получения отчетов — в Access имеются средства конструирования форм, запросов, отчетов и страниц. Объекты приложений состоят из графических элементов, называемых элементами управления. Основные элементы управления служат для связи объектов с записями таблиц, являющихся источниками данных.
При создании приложений пользователя также используются средства программирования, реализуемые объектами другого типа — макросами и модулями на языке программирования Visual Basic for Applications (VBA).
Каждый объект и элемент управления имеет свои свойства, определяя которые, можно настраивать объекты и элементы управления. С каждым объектом и элементом управления связывается набор событий, которые могут обрабатываться макросами или процедурами на VBA.
Объекты представлены в окне базы данных Access. Все операции по работе с объектами базы данных и приложений начинаются в этом окне.
|
