ТПБДиЗ ЛР№1 (604)
.pdfКафедра «Экономической кибернетики и информационных технологий»
МЕТОДИЧЕСКИЕ УКАЗАНИЯ
к выполнению лабораторной работы № 1
«Разработка, заполнение и корректировка таблиц базы данных»
по курсу «Технология проектирования баз данных и знаний»
(для студентов экономических специальностей)
Рекомендовано на заседании кафедры ЭКиИТ
Протокол № 2 от 13.09.02
Утверждено на заседании методсовета ДГМИ
Протокол № 2 от 15.11.02
Алчевск, 2002
УДК У.в6
Методические указания к выполнению лабораторной работы № 1 «Разработка, заполнение и корректировка таблиц базы данных» по курсу «Технология проектирования баз данных и знаний» (для студентов экономических специальностей) / Сост.: Е.Е.Бизянов. – Алчевск: ДГМИ, 2002. – 39 с.
Рассмотрен процесс разработки таблиц базы данных с помощью программы Microsoft Access. Приведен пример разработки. Приведены индивидуальные задания, требования к отчету, сформулирован ряд вопросов для самопроверки.
Составитель |
Е.Е. Бизянов, доц. |
Ответственный редактор |
С.И. Зайцев, проф. |
Ответственный за выпуск |
Н.Н. Лепило, доц. |
УДК У.в6
Методичні вказівки до виконання лабораторної роботи № 1 «Розробка, заповнення та коректування таблиць бази даних» за курсом «Технологія проектування баз даних та знань» (для студентів економічних спеціальностей) / Укл.: Є.Є. Бізянов. – Алчевськ: ДГМІ, 2002. – 39 с.
Розглянуто процес розробки таблиць бази даних за допомогою програми Microsoft Access. Приведено приклад розробки. Приведено індивідуальні завдання, вимоги до звіту, а також сформульований ряд питань для самоперевірки.
Укладач |
Є.Є.Бізянов, доц. |
Відповідальний редактор |
С.І.Зайцев, проф. |
Відповідальний за випуск |
Н.М.Лепіло, доц. |
2
Цель работы: научиться с помощью программы Microsoft Access создавать таблицы базы данных, вводить данные и корректировать их; связывать таблицы; обеспечивать целостность данных.
1 БАЗЫ ДАННЫХ – ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ
Банк данных (БнД) – это система специальным образом организованных данных (баз данных), программных, технических, языковых, организационнометодических средств, предназначенных для централизованного накопления и коллективного многоцелевого использования этих данных.
База данных (БД) – поименованная структурированная совокупность взаимосвязанных данных, относящихся к конкретной предметной области и находящихся под централизованным программным управлением. Программное управление осуществляется системой управления базами данных (СУБД), по-
средством которой пользователь может определять, создавать и поддерживать БД, а также осуществлять к ней контролируемый доступ.
Предметной областью называется часть реального мира, представляющая интерес для использования и отраженная в информационной системе.
В настоящее время наибольшее распространение получили реляционные базы данных. Американский математик Э. Ф. Кодд в 1970 году в своей статье «Реляционная модель данных для больших совместно используемых банков данных» впервые сформулировал основные понятия и ограничения реляционной модели, ограничив набор операций в ней семью основными и одной дополнительной операцией.
Основные положения реляционной модели данных:
∙Высокая степень независимости от данных, что обеспечивает независимость прикладных программ от внутреннего представления данных (изменения способа организации данных, путей доступа и пр.).
∙Решение проблем непротиворечивости и избыточности данных путем
нормализации отношений.
∙Расширение возможностей языков управления данными за счет добавления операций над множествами.
Коммерческие системы на основе реляционной модели данных начали появляться уже в 70-х годах прошлого столетия. Сейчас известны десятки разных реляционных СУБД, наиболее яркими представителями которых являются:
3
MS Access, MS FoxPro, Paradox, dBase, R:Base.
Реляционная модель основана на математическом понятии отношения, которое представлено таблицей. Именно поэтому модель получила название реляционной (от английского relation — отношение).
Отношение обычно имеет вид двумерной таблицы, в которой строки соответствуют различным записям, а столбцы – атрибутам. Атрибуты могут располагаться в произвольном порядке, т.к. при их переупорядочивании отношение будет иметь один и тот же смысл.
Рассмотрим пример базы данных, имеющей две таблицы. В первой таблице (DEPT – отделения) – содержится информация о подразделениях фирмы:
DEPT – код подразделения; DNAME – название подразделения;
BUDGET – годовой бюджет подразделения.
Во вторую таблицу заносятся данные о работниках: EMP – код работника;
ENAME – фамилия работника;
DEPT – код подразделения, в котором работает работник; SALARY – годовая заработная плата работника.
DEPT |
|
|
EMP |
|
|
|
||
|
DEPT |
DNAME |
BUDGET |
|
EMP |
ENAME |
DEPT# |
SALARY |
|
D1 |
Маркетинга |
20M |
|
E1 |
Иванов |
D1 |
20к |
|
D2 |
Развития |
10M |
|
E2 |
Петров |
D1 |
22к |
|
D3 |
Исследований |
5M |
|
E3 |
Семенов |
D2 |
15к |
|
|
|
|
|
E4 |
Григорьев |
D2 |
5к |
Для краткости числовые данные в таблицах представлены с использованием приставок: М – миллионов, к – тысяч.
Над таблицами БД можно выполнять ряд операций. Рассмотрим некоторые из них:
1. Выборка из таблицы DEPT отделов, у которых BUDGET > 8M.
|
DEPT |
|
DNAME |
|
BUDGET |
|
|||
|
D1 |
|
Маркетинга |
|
|
20М |
|
||
|
D2 |
|
|
Развития |
|
|
10М |
|
|
2. Извлечение таблицы DEPT столбцов DEPT и BUDGET. |
|||||||||
|
|
|
|
|
|||||
|
|
DEPT |
BUDGET |
||||||
|
|
D1 |
|
20М |
|
|
|
|
|
|
|
D2 |
|
10М |
|
|
|
|
|
|
|
D3 |
|
5M |
|
|
|
|
|
|
|
|
|
|
|
4 |
|
|
3. Объединение таблиц DEPT и EMP на основе столбца DEPT.
DEPT |
DNAME |
BUDGET |
EMP# |
ENAME |
SALARY |
|
|
|
|
|
|
D1 |
Маркетинга |
20М |
E1 |
Иванов |
20к |
|
|
|
|
|
|
D1 |
Маркетинга |
20Ь |
E2 |
Петров |
22к |
|
|
|
|
|
|
D2 |
Развития |
10М |
E3 |
Семенов |
15к |
|
|
|
|
|
|
D2 |
Развития |
10М |
E4 |
Григорьев |
5к |
|
|
|
|
|
|
Как видно из приведенных примеров, результат любой из операций – новая таблица. В этом проявляется реляционное свойство замкнутости, означающее, что результат операции над объектом – объект такого же рода. Т.о. над результатом операции можно проделать другую операцию и т.д. Иначе говоря, можно использовать вложенные выражения, в которых операнды – тоже выражения, а не объекты.
Особенностью реляционной модели является также то, что операции применяются ко всему множеству строк, а не к каждой отдельно взятой строке, т.е. операндами являются целые таблицы, содержащие множество строк.
Рассмотрим подробнее таблицу БД (рисунок 1.1).
Рисунок 1.1 – Таблица реляционной базы данных
Из рисунка видны основные составляющие отношения (таблицы БД): Кортеж (запись) – строка таблицы.
Атрибут (поле) – столбец таблицы (поименованный столбец отношения). Кардинальное число – количество кортежей в отношении (строк в таб-
5
лице).
Степень отношения – количество столбцов (полей) в отношении. Первый столбец (поле) отмечен знаком #, говорящим о том, что данное
поле является ключевым. Различают несколько разновидностей ключей: суперключ, первичный, внешний и потенциальный ключ.
Суперключ – атрибут или множество атрибутов, однозначно идентифицирующий кортеж отношения.
Первичный ключ – уникальный идентификатор отношения (столбец, комбинация столбцов), причем такой, что для одного ключа не существует двух строк, содержащих одинаковые значения в таком столбце или комбинации столбцов.
Потенциальный ключ – это суперключ, не содержащий подмножества, также являющегося суперключом данного отношения.
Потенциальный ключ обладает двумя свойствами:
∙Уникальность – в каждом кортеже отношения значение ключа однозначно идентифицирует этот кортеж
∙Неприводимость – никакое допустимое подмножество ключа не обладает свойством уникальности
Т.о., первичный ключ – это потенциальный ключ, выбранный для уникальной идентификации доменов внутри отношения.
Внешний ключ – атрибут или множество атрибутов внутри отношения, которые соответствуют потенциальному ключу некоторого (может быть того же самого) отношения.
В приведенном ранее примере в таблице DEPT атрибут DEPT является первичным ключом, в таблице EMP – EMP является первичным ключом, а DEPT# – внешним.
Таким образом, ключи позволяют однозначно идентифицировать составляющие отношений и осуществлять связь между ними.
Столбец таблицы в теории реляционных БД обычно называется доменом. Домен – совокупность значений, из которых берутся настоящие значения для определенных атрибутов определенного отношения. Так, например, домен
DEPT – это множество всех допустимых значений кода подразделения, а множество значений DEPT в отношении DEPT в любой момент времени является подмножеством этого множества.
В таблице 1.1 приведено соответствие терминов, использующихся в литературе по БД и СУБД.
6
Таблица 1.1 – Соответствие терминов
Реляционная терминология |
Неформальная терминология |
|
|
Отношение |
Таблица |
|
|
Кортеж |
Строка таблицы (запись) |
|
|
Кардинальное число |
Количество строк |
|
|
Атрибут |
Столбец (поле) |
|
|
Степень |
Количество столбцов (полей) |
|
|
Первичный ключ |
Уникальный идентификатор |
|
|
Домен |
Общая совокупность допусти- |
|
мых значений |
|
|
Домен является наименьшей семантической единицей данных. Домены обладают свойством атомарности, т.е. они неразложимы. Например, имя человека имеет внутреннюю структуру, т.к. оно разложимо на буквы. Однако, разложив его на буквы, мы потеряем значение. Т.о. домен – это именованное множество значений одного типа.
Домены – чрезвычайно мощный компонент реляционной модели. Каждый атрибут реляционной БД определяется на некотором домене. Домены могут быть различными для каждого из атрибутов, но два и даже более атрибутов могут быть определены на одном домене.
Например, есть БД, содержащая информацию о компании в виде двух отношений (таблиц): Отделения и Сотрудники.
Отделения
Оном |
Улица |
Область |
Город |
Индекс |
Тел_ном |
Факс_ном |
|
|
|
|
|
|
|
О1 |
Кутузова,11 |
Харьковская |
Чугуев |
61015 |
5-16-01 |
5-17-11 |
|
|
|
|
|
|
|
О2 |
Кирова,2 |
Луганская |
Алчевск |
94201 |
2-16-19 |
2-16-19 |
|
|
|
|
|
|
|
О3 |
Советская,123 |
Киевская |
Киев |
10001 |
242-16-05 |
242-16-07 |
|
|
|
|
|
|
|
7
Сотрудники
Сном |
Имя |
Фами- |
Тел_ |
Долж- |
П |
ДР |
ЗП |
ИНН |
О |
лия |
ном |
ность |
о |
но |
|||||
|
|
л |
|
|
|
м |
|||
|
|
|
|
|
|
|
|
||
С11 |
Анна |
Крылова |
222-12-33 |
Менед- |
Ж |
10.11.69 |
18000 |
1122211 |
О3 |
|
|
|
|
жер |
|
|
|
|
|
С21 |
Петр |
Ивнев |
2-12-27 |
Менед- |
М |
01.03.75 |
10000 |
2223334 |
О1 |
|
|
|
|
жер |
|
|
|
|
|
С44 |
Олег |
Петров |
344-56-91 |
Дирек- |
М |
01.10.80 |
50000 |
1110066 |
О3 |
|
|
|
|
тор |
|
|
|
|
|
С105 |
Инна |
Белая |
553-16-11 |
Секре- |
Ж |
22.12.81 |
8000 |
2345670 |
О3 |
|
|
|
|
тарь |
|
|
|
|
|
Рассмотрим теперь домены атрибутов отношений Отделения и Сотрудники (таблица 1.1).
Таблица 1.2 – Домены атрибутов отношений
Атрибут |
Имя домена |
Содержимое домена |
Определение |
|
домена |
||||
|
|
|
||
|
|
|
|
|
Оном |
Номера_отделений |
Множество всех допус- |
Символьный: размер |
|
|
|
тимых номеров отделе- |
3, диапазон ‘О1- |
|
|
|
ний фирмы |
О99’ |
|
Улица |
Названия_улиц |
Множество всех назва- |
Символьный: размер |
|
|
|
ний улиц в Украине |
25 |
|
Область |
Названия_областей |
Множество всех назва- |
Символьный: размер |
|
|
|
ний областей в Украине |
15 |
|
Город |
Названия_городов |
Множество всех назва- |
Символьный: размер |
|
|
|
ний городов в Украине |
15 |
|
Индекс |
Индексы |
Множество всех индек- |
Символьный: размер |
|
|
|
сов в Украине |
5 |
|
Тел_ном |
Номера_ телефо- |
Множество всех номе- |
Символьный: размер |
|
|
нов_и_факсов |
ров телефонов и факсов |
10 |
|
|
в Украине |
|
||
|
|
|
||
Факс_ном |
Номера_ телефо- |
Множество всех номе- |
Символьный: размер |
|
|
нов_и_факсов |
ров телефонов и факсов |
10 |
|
|
в Украине |
|
||
|
|
|
||
Пол |
Пол |
Пол человека |
Символьный: размер |
|
|
|
|
1, значение ‘М’ или |
|
|
|
|
’Ж’ |
|
ДР |
Все возможные даты |
Все возможные значе- |
Дата, диапазон от |
|
|
работников фирмы |
ния даты рождения со- |
01.01.40, формат |
|
|
трудников фирмы |
dd.mm.yy |
||
|
|
|||
ЗП |
Зарплаты |
Все возможные значе- |
Денежный: 6 цифр, |
|
|
|
ния годовой зарплаты |
диапазон 1500.00 – |
|
|
|
сотрудников |
100000.00 грн. |
8
Из приведенной таблицы видно, что два атрибута, «Тел_ном» и «Факс_ном» определены на одном домене «Номера_телефонов_и_факсов».
Таким образом, домен – это ни что иное, как тип данных.
Благодаря доменам пользователь может определять смысл и источник значений, которые могут получать атрибуты. В результате при выполнении реляционной операции системе доступно больше информации, что позволяет ей избежать семантически некорректных операций. Например, нет смысла сравнивать название улицы с номером телефона, хотя для этих атрибутов домены определены на символьных строках. С другой стороны, месячная арендная плата объекта недвижимости и количество месяцев, в течение которых он сдавался в аренду, принадлежат разным доменам (первый атрибут имеет денежный тип, второй – целочисленный). Однако умножение значений из этих доменов является допустимой операцией.
Исторически вокруг такого относительно простого понятия, как отношение, сложилась некоторая двусмысленность. Причина кроется в отсутствии четкого разграничения между переменными отношений и значениями отношений. Переменная отношения – это обычная переменная, такая же как и к языках программирования, т.е. именованный объект, значение которого может изменяться со временем. А значение этой переменной в любой момент времени и будет значением отношения. Так с помощью выражения
CREATEBASERELATIONS .. . ;
создается переменная отношения с именем S, значение которой в любой момент времени будет определенным значением отношения.
Например, если мы в некотором языке программирования (например, Basic) объявим переменную QTY следующим образом:
DimQTYAsInteger,
то эту переменную мы будем называть не целым числом, а переменной целого типа, потому что целыми числами являются значения этой переменной, а не сама переменная.
Отношение R, определенное на множестве доменов D1, D2,..,Dn (не обязательно различных), содержит две части: заголовок и тело. (Если представить отношение в терминах таблиц, то заголовок – это строка названий столбцов, а тело – это множество строк данных.).
Заголовок содержит фиксированное множество атрибутов или, точнее, пар <имя-атрибута:имя-домена>:
9
{ <A1:D1>, <A2:D2>, ... <Al:Dn>},
причем каждый атрибут Aj соответствует одному и только одному из лежащих в основе доменов Dj (j = 1,2,..., n). Все имена атрибутов A1, А2, ...,Аn разные.
Тело содержит множество кортежей. Каждый кортеж, в свою очередь, содержит множество пар <имя - атрибута: значение - атрибута>:
{ <A1:vi1>, <А2: vi2>,..., <An: vin> }, i = 1, 2, ..., m,
где m — количество кортежей в этом множестве.
Вкаждом таком кортеже есть одна такая пара <имя - атрибута: значение - атрибута>, т.е. <Aj:vij>, для каждого атрибута Aj в заголовке. Для любой такой пары <Aj:vij> vij является значением из уникального домена Dj, который связан с атрибутом Aj. Значения m и n – соответственно кардинальное число и степень отношения К.
Вкачестве примера рассмотрим таблицу S, приведенную в самом начале, чтобы проверить, можно ли назвать ее отношением.
∙Во-первых, в этой таблице есть четыре основных домена, а именно: домен номеров поставщиков (S#), домен имен (NAME), домен значений статуса (STATUS) и домен наименований городов (CITY). (Изображая отношение как таблицу на листе бумаги, мы обычно не заботимся о том, чтобы показать лежащие
воснове домены, но должны понимать, что, по крайней мере концептуально, что они всегда есть.)
∙Далее, в таблице непременно есть две части: строка заголовков столбцов, а также множество строк данных. Рассмотрим вначале строку заголовков столбцов:
{ S#, NAME, STATUS, CITY }
Эта строка в действительности представляет набор упорядоченных пар:
{ <S# |
:S# |
>, |
<SNAME |
:NAME |
>, |
<STATUS |
:STATUS |
>, |
<CITY |
:CITY |
> } |
Первый компонент каждой пары – это имя атрибута, второй компонент – имя соответствующего домена. Поэтому можно условиться, что строка заголовков столбцов действительно представляет собой заголовок. На практике заголовок отношения обычно рассматривают просто как набор имен атрибутов (т.е. имена доме-
10