Главная страница

Пример базы данных. 6. 1Инструкция для пользователя по работе с ис 39


Скачать 1.57 Mb.
Название6. 1Инструкция для пользователя по работе с ис 39
АнкорПример базы данных
Дата03.06.2022
Размер1.57 Mb.
Формат файлаdocx
Имя файлаprimer_BD.docx
ТипОтчет
#566894
страница1 из 2
  1   2

Оглавление


1. Анализ предметной области. 2

1.1.Описание предметной области (ПО) решаемой задачи. 2

1.2 Описание нормативно-справочной информации и оперативной информации, которая используется в ПО. 3

1.3 Описание входных документов и их реквизитов, которые необходимо сохранить в БД. 4

1.4 Описание содержания и вида отчетных документов. 5

2. Разработка концептуальной модели данных предметной области 6

2.1Описание информационных объектов (сущностей), их атрибутов 6

2.2 Построение концептуальной модели базы данных 6

2.3Нормализация информационных объектов 7

2.4 Построение информационно-логической модели БД в виде диаграммы «Сущность-Связь». 8

3.1Описание выбранной СУБД 9

3.2 Представление ИЛМ в виде таблиц реляционной базы данных с описанием логической структуры таблиц 11

3.3Описание требуемых запросов к базе данных на основе разработанных таблиц реляционной БД 15

3.4Описание формирования, содержания и вида выходных документов (отчетов) 17

4.Разработка физической модели базы данных 18

4.1Создание структуры и связей проектируемой базы данных 18

4.2Создание таблиц проектируемой БД 18

4.3Создание форм для ведения проектируемой БД 23

4.4Создание запросов проектируемой БД 27

4.5Создание отчетов проектируемой БД 31

5.Разработка пользовательского приложения – информационной системы (ИС) – на основе созданной базы данных 35

5.1Схема функциональной структуры приложения 35

5.2Формы заставки, главной и вторичной кнопочных форм диалога пользователя, процедуры обработки событий, макросы. 36

6.Документирование информационной системы на основе БД 39

6.1Инструкция для пользователя по работе с ИС 39

6.2 Инструкция для администратора БД 41

Список литературы 43


1. Анализ предметной области.

    1. Описание предметной области (ПО) решаемой задачи.

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

По мере своего развития административные системы обработки данных перерастают в автоматизированные системы управления соответствующими объектами, в которых, как правило, не ограничиваются одной ЭВМ, а в составе двух и более ЭВМ объединяют в вычислительный комплекс. В этом ряду особое место занимают базы данных и другое программное обеспечение, связанное с их использованием в качестве инструмента для делопроизводства и рационализации труда. Их использование позволяет сократить время, требуемое на подготовку конкретных маркетинговых и производственных проектов, уменьшить непроизводительные затраты при их реализации, исключить возможность появления ошибок в подготовке бухгалтерской, технологической и других видов документации, что дает для предприятия прямой экономический эффект.

Туристические фирмы также заинтересованы в развитии системы документооборота, так как в процессе деятельности ими обрабатываются большие объемы информации. Им необходимо оперативно отслеживать информацию об изменении экономической и политической ситуации в странах, развивающих туристический бизнес, собирать и обрабатывать сведения о клиентах, для возможности организации адресных рекламных компаний, разработки ценовой политики, организации популярных туристических туров и т.д.

Кроме того, туристическая фирма должна отслеживать данные о заказах, для начисления премий сотрудникам, выполнившим плановые показатели, для анализа выполненных и отложенных договорных обязательств перед заказчиками.

Информация о туристических турах должна содержать даты отправления и прибытия, необходимость бронирования пансионатов и отелей, заказы чартерных рейсов или бронирование билетов в железнодорожных, авиационных или морских транспортных системах.

Кроме того в фирме должен проводится анализ востребованности туров, для снижения их себестоимости, своевременной реализации оставшихся путевок (например, для заполнения чартерных рейсов) и конкурентноспособного ценообразования.

Так как при формировании туров приходится обращаться в одни и те же организации для предоставления услуг перевозки пассажиров, гостиничных услуг, экскурсионных туров и т.д., то фирме необходимо вести справочник контрагентов. При этом можно разграничивать наборы контрагентов по виду предоставляемых ими услуг.
1.2 Описание нормативноправочной информации и оперативной информации, которая используется в ПО.

Целью курсовой работы является разработка базы данных, позволяющей автоматизировать систему документооборота туристической фирмы.

В результате анализа операций, выполняемых сотрудниками фирмы можно выделить ряд задач, которые должна решать разрабатываемая база данных:

  1. добавление, удаление и корректировка данных об имеющихся сотрудниках;

  2. добавление новых сотрудников при приеме на работу;

  3. удаление данных об уволившихся сотрудниках;

  4. добавление, удаление и корректировка анкетных данных клиентов;

  5. добавление данных впервые обратившихся клиентов;

  6. добавление новых заказов;

  7. добавление, удаление и корректировка данных об имеющихся турах;

  8. добавление новых туристических маршрутов;

  9. добавление, удаление и корректировка данных имеющихся контрагентов;

  10. добавление новых контрагентов при заключении с ними договора;

  11. добавление новых договоров об оказании услуг сторонними организациями;

  12. добавление или редактирование списка услуг, предоставляемых сторонними организациями;

  13. автоматическая индексация цен, связанная с изменением курса доллара и евро и текущим уровнем инфляции;

  14. автоматическая индексация зарплат сотрудников, обусловленная текущим уровнем инфляции.

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

В связи с выделенными в пункте 1.1 сущностями предметной области можно сделать вывод, что в базу данных должны вводиться следующие документы:

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

  2. анкета клиента, содержащая фамилию, имя, отчество, дату рождения, адрес регистрации, контактный телефон;

  3. бланк заказа, содержащий сведения о выбранном туристическом туре, оформившем заказ сотруднике, заказавшем тур клиенте и дате оформления заказа;

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

  5. рекламные буклеты, состоящие из наименования страны, названия курорта и стоимости тура;

  6. справочника контрагентов, содержащего название контрагента, его адрес, и контактное лицо: должность, фамилию, имя, отчество, телефон;

  7. списка договоров, содержащих название контрагента и дату заключения договора.


1.4 Описание содержания и вида отчетных документов.

Результатом работы программы должен быть следующий набор документов:

  1. зарплатная ведомость, упорядоченная и сгруппированная по должностям сотрудников и содержащая кроме должности их фамилию, имя, отчество и размер заработной платы;

  2. список клиентов, содержащий фамилию, имя, отчество каждого клиента, его адрес и телефон;

  3. картотека заказов с возможностью автоматического поиска заказа по его номеру;

  4. список доступных на настоящий момент туров, состоящий из сведений о стране, курорте, транспортных средствах, условиях проживания, запланированных экскурсиях и стоимости;

  5. список контрагентов, содержащий название организации и сведения о контактном лице, его должности, телефоне и ФИО.


2. Разработка концептуальной модели данных предметной области

    1. Описание информационных объектов ущностей), их атрибутов

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

На основании формализации требований к документообороту туристической фирмы можно выделить следующие сущности, участвующие в работе БД.

  1. Сотрудник. Атрибуты: фамилия, имя, отчество, дата рождения, зарплата, должность, прописка, телефон.

  2. Клиент. Атрибуты: фамилия, имя, отчество, дата рождения, прописка, телефон.

  3. Заказ. Атрибуты: выбранный тур, оформивший заказ сотрудник, заказавший тур клиент, дата заказа.

  4. Тур. Атрибуты: тип тура, страна, курорт, транспорт, виза, проживание, отель, информация о питании, дата отправления, дата прибытия, стоимость.

  5. Договор. Атрибуты: название контрагента, дата заключения.

  6. Контрагент. Атрибуты: название, адрес, должность, ФИО, телефон контактного лица, тип услуг.




    1. Построение концептуальной модели базы данных

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

Клиент выбирает тур, делает заказ, подписывает договор.

Тур входит в заказ.

Заказ формирует договор.

Сотрудник взаимодействует с контрагентом, оформляет заказ, составляет договор.

Контрагент обслуживает тур.



Рисунок 1 – Концептуальная модель


    1. Нормализация информационных объектов

Нормализация – упрощение структуры БД, но с таким условием, чтобы на полученном множестве отношений можно было бы восстановить исходные функциональные зависимости.

Информационные объекты находятся в первой нормальной форме, так как все их атрибуты атомарны (не делимы).

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

Теперь информационные объекты находятся во второй нормальной форме, так как они находятся в первой нормальной форме и каждый не ключевой атрибут полностью зависит от ключа.

Информационные объекты находятся в третьей нормальной форме, так как они находятся во второй нормальной форме и отсутствует зависимость между не ключевыми атрибутами.


    1. Построение информационно-логической модели БД в виде диаграммы «Сущность-Связь».

Для того, чтобы проектировать информационно-логическую модель БД, необходимо проанализировать концептуальную схему проектируемой БД, выделить и отбросить избыточные связи, а оставшиеся связи проименовать.



Рисунок 2 – Инфологическая модель

3. Построение логической модели базы данных.

    1. Описание выбранной СУБД

Microsoft Access – это СУБД для WINDOWS, реализующая реляционную модель данных. Для работы используется встроенный формат mdb или форматы других популярных БД dBASE, Paradox или Btrieve без их конвертирования. Для осуществления поиска по БД и манипулирования данными можно использовать язык Access Basic (оптимизированый для БД Visual Basic) или MS SQL.

Приватность доступа реализуется уже на этапе открытия БД, т.е. можно наложить пароль при входе в базу либо ограничить возможность доступа лишь просмотром информации без возможности редактирования, причем в Access предусмотрена два режима такой работы Read Only – для просмотра данных и Exclusive для предотвращения изменений.

Access реляционная СУБД, поэтому вся информация содержится в таблицах, каждое поле которых имеет свой тип, однозначно определяющий характер хранимой в этой ячейке информации. Тип данных можно выбрать из предоставленных по шаблону, либо можно изменить настройки типа для наложения дополнительных ограничений, например маски ввода или подстановки ключевых полей других записей.

Готовая БД способна расширяться, но лучше этого избежать в связи с тем, что попытка изменить параметры готовой БД может повлечь за собой изменение или искажение существующей в БД информации.

Манипулирование данными в среде Access осуществляется при помощи запросов, позволяющих отобрать только необходимую в данный момент информацию, которая соответствует определенным критериям поиска, т.к. данные выводимые в результате запроса динамические, то они перестраиваются каждый раз на основе актуализированной информации.

Все запросы можно разделить на две части:

  • QBE-запросы (Query by Example - Запрос по образцу);

  • SQL - запросы (Structured Query Language - Структурированный язык запросов).

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

Кроме запросов на выборку пользователи могут создавать запросы с вычислениями данных в блоках, например, вычисление процентов от заданного поля или суммирование значений по полям.

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

Язык SQL позволяет пользователю создавать запросы, оперирующие большим количеством данных и параметров, и выполняющие вычисления по сложным, нестандартным формулам.

Работа с информацией БД возможна как в виде таблицы, так и с помощью специальных форм, позволяющих настроить отображение отдельной записи на экране так, как это удобно пользователю.

Результаты обработки данных удобно представлять в виде отчетов, представляющих выборку информации из БД в соответствии с заданными спецификациями. Например, это может быть часть таблицы, или результат запроса. Отчеты оптимизированы для вывода на печать и распространения.

Так же как и запросы, отчеты создается по готовым шаблонам либо с помощью конструктора, при этом в отчет можно встроить управляющие элементы, которые можно использовать для оформления распечатываемого документа, кроме того с их помощью можно актуализировать данные отчета.

Вывод: для достижения поставленной в работе цели лучше всего использовать СУБД MS Access, так как этот вид СУБД позволяет решить поставленные задачи, удовлетворяет по производительности и надежности, и, кроме того, входит в состав пакета офисных приложений MS Office, а, следовательно, небольшим компаниям не придется тратить дополнительные средства для получения лицензии на использование СУБД.


    1. Представление ИЛМ в виде таблиц реляционной базы данных с описанием логической структуры таблиц

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

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

Таблица «Сотрудник» должна содержать фамилию, имя, отчество, дату рождения, размер заработной платы, занимаемую должность, адрес регистрации, контактный телефон. Сведем данные атрибутов сущности «Сотрудник» в таблицу.

Таблица 1 – Модель сущности «Сотрудник»

Имя поля

Тип данных

Размер

Ключевое поле

Связь с другой таблицей

Код сотрудника

Счетчик




Да

«Заказы»

Код сотрудника

Фамилия

Текстовый

15

Нет




Имя

Текстовый

10

Нет




Отчество

Текстовый

15

Нет




Дата рождения

Дата



Нет




Зарплата

Денежный




Нет




Должность

Текстовый

10

Нет




Адрес

Текстовый

20

Нет




Телефон

Текстовый

9

Нет




Таблица «Клиент» должна содержать фамилию, имя, отчество, дату рождения, адрес регистрации, контактный телефон. Сведем данные атрибутов сущности «Клиент» в таблицу.

Таблица 2 – Модель сущности «Клиент»

Имя поля

Тип данных

Размер

Ключевое поле

Связь с другой таблицей

Код клиента

Счетчик




Да

«Заказы»

Код клиента

Фамилия

Текстовый

15

Нет




Имя

Текстовый

10

Нет




Отчество

Текстовый

15

Нет




Адрес

Текстовый

20

Нет




Телефон

Текстовый

9

Нет




Таблица «Заказ» должна содержать сведения о выбранном туристическом туре, оформившем заказ сотруднике, заказавшем тур клиенте и дате оформления заказа. Сведем данные атрибутов сущности «Заказ» в таблицу.

Таблица 3 – Модель сущности «Заказ»

Имя поля

Тип данных

Размер

Ключевое поле

Связь с другой таблицей

Код заказа

Счетчик




Да




Код тура

Числовой




Нет

«Туры»

Код тура

Код сотрудника

Числовой




Нет

«Сотрудники»

Код сотрудника

Код клиента

Числовой




Нет

«Клиенты»

Код клиента

Дата оформления

Дата



Нет




Таблица «Туры» должна содержать тип услуги, название страны и курорта, вид транспортного средства, необходимость визы, потребность в проживании и тип отеля, включено или нет питание и его тип, имеющиеся в рамках тура экскурсии, даты отправления и прибытия, стоимость тура. Сведем данные атрибутов сущности «Туры» в таблицу.

Таблица 4 – Модель сущности «Туры»

Имя поля

Тип данных

Размер

Ключевое поле

Связь с другой таблицей

Код тура

Счетчик




Да

«Заказы»

Код тура

Код услуги

Числовой




Нет

«Услуги»

Код услуги

Страна

Текстовый

15

Нет




Курорт

Текстовый

20

Нет




Транспорт

Текстовый

10

Нет




Визовое обслуживание

Логический




Нет




Проживание

Логический




Нет




Тип проживания

Текстовый

10

Нет




Питание

Логический




Нет




Тип питания

Текстовый

10

Нет




Экскурсии

Логический




Нет




Дата отправления

Дата




Нет




Дата прибытия

Дата




Нет




Стоимость тура

Денежный




Нет




Таблица «Услуги» должна содержать сведения о поставщике и дате оказания услуги. Сведем данные атрибутов сущности «Услуги» в таблицу.

Таблица 5 – Модель сущности «Услуги»

Имя поля

Тип данных

Размер

Ключевое поле

Связь с другой таблицей

Код услуги

Счетчик




Да

«Туры»

Код услуги

Код поставщика

Числовой




Нет

«Поставщики»

Код поставщика

Дата исполнения

Дата




Нет




Таблица «Поставщики» должна содержать название поставщика, его адрес, и контактное лицо: должность, фамилию, имя, отчество, телефон. Сведем данные атрибутов сущности «Поставщики» в таблицу.

Таблица 6 – Модель сущности «Поставщики»

Имя поля

Тип данных

Размер

Ключевое поле

Связь с другой таблицей

Код поставщика

Счетчик




Да

«Услуги»

Код поставщика

Название Поставщика

Текстовый

20

Нет




Представитель Поставщика

Текстовый

10

Нет




Обращаться

Текстовый

30

Нет




Телефон

Текстовый

9

Нет




Адрес

Текстовый

20

Нет






    1. Описание требуемых запросов к базе данных на основе разработанных таблиц реляционной БД

Для реализации задач, стоящих перед пользователями разрабатываемой БД, необходимо создать ряд запросов:

  1. Запрос на выборку, выдающий список доступных туров в заданной стране, который будет формировать следующий набор полей таблицы «Туры»: страна, курорт, визовое обслуживание, проживание, питание, экскурсии, стоимость тура.

SQL форма запроса:

SELECT Туры.Страна, Туры.Курорт, Туры.[Визовое обслуживание], Туры.Проживание, Туры.Питание, Туры.Экскурсии, Туры.[Стоимость тура]

FROM Туры

WHERE (((Туры.Страна)=[Введите страну]));

  1. Многотабличный запрос, выдающий информацию о заказах по введенному номеру, который содержит данные из таблицы «Заказы»: код заказа, код тура, код сотрудника, код клиента, дата оформления; из таблицы «Сотрудники»: фамилия, имя, отчество, должность; из таблицы «Клиенты»: фамилия, имя, отчество; из таблицы «Туры»: страна и курорт.

SQL форма запроса:

SELECT Заказы.[Код заказа], Заказы.[Код тура], Заказы.[Код сотрудника], Заказы.[Код клиента], Заказы.[Дата оформления], Сотрудники.Фамилия AS Сотрудники_Фамилия, Сотрудники.Имя AS Сотрудники_Имя, Сотрудники.Отчество AS Сотрудники_Отчество, Сотрудники.Должность, Клиенты.Фамилия AS Клиенты_Фамилия, Клиенты.Имя AS Клиенты_Имя, Клиенты.Отчество AS Клиенты_Отчество, Туры.Страна, Туры.Курорт

FROM Туры INNER JOIN (Сотрудники INNER JOIN (Клиенты INNER JOIN Заказы ON Клиенты.[Код клиента] = Заказы.[Код клиента]) ON Сотрудники.[Код сотрудника] = Заказы.[Код сотрудника]) ON Туры.[Код тура] = Заказы.[Код тура]

WHERE (((Заказы.[Код заказа])=[Введите код заказа]));

  1. Запрос на выборку, выдающий список клиентов по введенной фамилии клиента или его номеру в базе, содержащий поля таблицы «Клиенты»: код клиента, фамилия, имя, отчество, адрес, телефон.

SQL форма запроса:

SELECT Клиенты.[Код клиента], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Адрес, Клиенты.Телефон

FROM Клиенты

WHERE (((Клиенты.Фамилия)=[Введите фамилию клиента, если не помните, то нажмите "Ок"])) OR (((Клиенты.[Код клиента])=[Введите код клиента]));

  1. Запрос на выборку, выдающий список сотрудников по введенному коду сотрудника или его должности, содержащий поля таблицы «Сотрудники»: код сотрудника, фамилия, имя, отчество, должность, зарплата.

SQL форма запроса:

SELECT Сотрудники.[Код сотрудника], Сотрудники.Фамилия, Сотрудники.Имя, Сотрудники.Отчество, Сотрудники.Должность, Сотрудники.Зарплата

FROM Сотрудники

WHERE (((Сотрудники.[Код сотрудника])=[Введите код сотрудника, если не помните, то нажмите "Ок"])) OR (((Сотрудники.Должность)=[Введите должность сотрудника]));

  1. Запрос на выборку, выдающий список поставщиков по названию или по коду, содержащий поля таблицы «Поставщики»: код поставщика, его название и адрес, должность представителя поставщика, его ФИО и телефон.

SQL форма запроса:

SELECT Поставщик.[Код Поставщика], Поставщик.[Название Поставщика], Поставщик.[Представитель Поставщика], Поставщик.Обращаться, Поставщик.Телефон, Поставщик.Адрес

FROM Поставщик

WHERE (((Поставщик.[Название Поставщика])=[Введите название поставщика, если не помните, нажмите "Ок"])) OR (((Поставщик.[Код Поставщика])=[Введите код поставщика услуг]));

  1. Запрос на изменение, позволяющий увеличить на 20% стоимость туров, цена которых меньше 30000.

SQL форма запроса:

UPDATE Туры SET Туры.[Стоимость тура] = [Стоимость тура]*1.2

WHERE (((Туры.[Стоимость тура])<30000));

  1. Запрос на изменение, позволяющий увеличить на 5% зарплату сотрудников, тем из них, у кого зарплата меньше 22000.

SQL форма запроса:

UPDATE Сотрудники SET Сотрудники.Зарплата = [Зарплата]*1.05

WHERE (((Сотрудники.Зарплата)<22000));

    1. Описание формирования, содержания и вида выходных документов (отчетов)

  1. Список клиентов, состоящий из данных клиентов: фамилия, имя, отчество, адрес, телефон, содержащий текущую дату и нумерацию страниц.

  2. Список заказов по введенному коду, содержащий название страны, название курорта, код заказа, дату оформления, фамилию, имя, отчество и должность сотрудника, оформившего заказ и код клиента, содержащий текущую дату и нумерацию страниц.

  3. Список поставщиков, состоящий из наименования организации поставщика и данных о его представителе: должность, фамилия, имя, отчество, контактный телефон, содержащий текущую дату и нумерацию страниц.

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

  5. Список туров, сгруппированный по странам, содержащий наименование курорта, вид транспорта, данные об условиях проживания и экскурсиях и стоимости тура, а также текущую дату и нумерацию страниц.



  1. Разработка физической модели базы данных

    1. Создание структуры и связей проектируемой базы данных

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

Первым шагом объединения данных БД в MS Access является определение связей между таблицами. После этого становится возможным создание запросов, форм и отчетов, а которых выводятся данные из нескольких таблиц сразу.

На уровне таблиц можно установить связи, используя, Конструктор связей.

Для того чтобы установить связи между таблицами, необходимо установить связи между теми полями, в которых содержится общая информация. Как правило, связь устанавливается соединением ключевых полей таблиц: первичного ключа в одной таблице и внешнего ключа в другой. Первичные ключи гарантируют уникальность записей в таблице. Общее поле связи в другой таблице может и не быть в ней первичным ключом (так обычно и бывает). Поле (или поля), используемое для связи с полем первичного ключа в другой таблице, называют внешним ключом. Внешним ключом может быть всякое поле, использованное для связи.

  1   2


написать администратору сайта