Что образуют данные в таблице бд

Связи между таблицами базы данных

1. Введение

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

1.1. Для кого эта статья?

Эта статья будет полезна тем, кто хочет разобраться со связями между таблицами базы данных. В ней я постарался рассказать на понятном языке, что это такое. Для лучшего понимания темы, я чередую теоретический материал с практическими примерами, представленными в виде диаграммы и запроса, создающего нужные нам таблицы. Я использую СУБД Microsoft SQL Server и запросы пишу на T-SQL. Написанный мною код должен работать и на других СУБД, поскольку запросы являются универсальными и не используют специфических конструкций языка T-SQL.

1.2. Как вы можете применить эти знания?

2. Благодарности

Учтены были советы и критика авторов jobgemws, unfilled, firnind, Hamaruba.
Спасибо!

3.1. Как организовываются связи?

Связи создаются с помощью внешних ключей (foreign key).
Внешний ключ — это атрибут или набор атрибутов, которые ссылаются на primary key или unique другой таблицы. Другими словами, это что-то вроде указателя на строку другой таблицы.

3.2. Виды связей

4. Многие ко многим

Представим, что нам нужно написать БД, которая будет хранить работником IT-компании. При этом существует некий стандартный набор должностей. При этом:

4.1. Как построить такие таблицы?

Слева указаны работники (их id), справа — должности (их id). Работники и должности на этой таблице указываются с помощью id’шников.

На эту таблицу можно посмотреть с двух сторон:

4.2. Реализация

С помощью ограничения foreign key мы можем ссылаться на primary key или unique другой таблицы. В этом примере мы

4.3. Вывод

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

5. Один ко многим

Эта самая распространенная связь между базами данных. Мы рассматриваем ее после связи многие ко многим для сравнения.

Предположим, нам нужно реализовать некую БД, которая ведет учет данных о пользователях. У пользователя есть: имя, фамилия, возраст, номера телефонов. При этом у каждого пользователя может быть от одного и больше номеров телефонов (многие номера телефонов).

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

Другими словами, телефон принадлежит только одному пользователю. А пользователю могут принадлежать 1 и более телефонов (многие).

Как мы видим, это отношение один ко многим.

5.1. Как построить такие таблицы?

Данная таблица представляет три номера телефона. При этом номера телефона с id 1 и 2 принадлежат пользователю с id 5. А вот номер с id 3 принадлежит пользователю с id 17.
Заметка. Если бы у таблицы «Phones» было бы больше атрибутов, то мы смело бы их добавляли в эту таблицу.

5.2. Почему мы не делаем тут таблицу-посредника?

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

5.3. Реализация

6. Один к одному

Представим, что на работе вам дали задание написать БД для учета всех работников для HR. Начальник уверял, что компании нужно знать только об имени, возрасте и телефоне работника. Вы разработали такую БД и поместили в нее всю 1000 работников компании. И тут начальник говорит, что им зачем-то нужно знать о том, является ли работник инвалидом или нет. Наиболее простое, что приходит в голову — это добавить новый столбец типа bool в вашу таблицу. Но это слишком долго вписывать 1000 значений и ведь true вы будете вписывать намного реже, чем false (2% будут true, например).

Более простым решением будет создать новую таблицу, назовем ее «DisabledEmployee». Она будет выглядеть так:

Но это еще не связь один к одному. Дело в том, что в такую таблицу работник может быть вписан более одного раза, соответственно, мы получили отношение один ко многим: работник может быть несколько раз инвалидом. Нужно сделать так, чтобы работник мог быть вписан в таблицу только один раз, соответственно, мог быть инвалидом только один раз. Для этого нам нужно указать, что столбец EmployeeId может хранить только уникальные значения. Нам нужно просто наложить на столбец EmloyeeId ограничение unique. Это ограничение сообщает, что атрибут может принимать только уникальные значения.

Выполнив это мы получили связь один к одному.

Заметка. Обратите внимание на то, что мы могли также наложить на атрибут EmloyeeId ограничение primary key. Оно отличается от ограничения unique лишь тем, что не может принимать значения null.

6.1. Вывод

Можно сказать, что отношение один к одному — это разделение одной и той же таблицы на две.

6.2. Реализация

7. Обязательные и необязательные связи

Связи можно поделить на обязательные и необязательные.

7.1. Один ко многим

У одной биологической матери может быть много детей. У ребенка есть только одна биологическая мать.

А) У женщины необязательно есть свои дети. Соответственно, связь необязательна.
Б) У ребенка обязательно есть только одна биологическая мать – в таком случае, связь обязательна.

7.2. Один к одному

У одного человека может быть только один загранпаспорт. У одного загранпаспорта есть только один владелец.

А) Наличие загранпаспорта необязательно – его может и не быть у гражданина. Это необязательная связь.
Б) У загранпаспорта обязательно есть только один владелец. В этом случае, это уже обязательная связь.

7.3. Многие ко многим

Человек может инвестировать в акции разных компаний (многих). Инвесторами какой-то компании являются определенные люди (многие).

А) Человек может вообще не инвестировать свои деньги в акции.
Б) Акции компании мог никто не купить.

8. Как читать диаграммы?

Выше я приводил диаграммы созданных нами таблиц. Но для того, чтобы их понимать, нужно знать, как их «читать». Разберемся в этом на примере диаграммы из пункта 5.3.

Мы видим отношение один ко многим. Одной персоне принадлежит много телефонов.

9. Итоги

10. Задачи

Для лучшего усвоения материала предлагаю вам решить следующие задачи:

Источник

Что такое База Данных (БД)

База данных — это место для хранения данных. Используется в том числе в клиент-серверной архитектуре. Это все интернет-магазины, сайты кинотеатров или авиабилетов. Вы делаете заказ, а система сохраняет ваши данные в базе.

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

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

Содержание

Что такое база данных

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

Катя решила открыть свой магазинчик. Она нашла хорошую марку обуви, которую «днем с огнем» не сыскать в ее городе. Заказала оптовую партию и стала потихоньку распродавать через знакомых. Пришлось освободить половину шкафа под коробки, но вроде всё поместилось.

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

Но покупатели хотят новинок, разных размеров. Да и самих покупателей становится все больше и больше. В шкаф коробки уже не влезают!

Теперь, если покупатель просит определенную пару, Катьке сложно её найти. Пока коробок было мало, она помнила наизусть, где что лежит. А теперь уже нет, да и все попытки организовать систему провалились. Места мало, да и детки любят с коробками поиграть.

Тогда Катька решила арендовать складское помещение. И вот теперь красота! Не надо теснить своих домашних, дома чисто и свободно! И на складе место есть, появилась система — тут босоножки, тут сапоги.

Чем больше объемы производства, тем больше нужно места. Если в начале пути склад не нужен, всё поместится дома, то потом это будет оправданно.

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

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

Как она выглядит

Да примерно как excel-табличка! Есть колонки с заголовками, и информация внутри:

Это называется реляционная база данных — набор таблиц, хранящихся в одном пространстве.

Что за пространство? Ну вот представьте, что вы храните все данные в excel. Можно запихать всю-всю-всю информацию в одну огро-о-о-о-мную таблицу, но это неудобно. Обычно табличек несколько: тут информация по клиентам, там по заказам, а тут по адресам. Эти таблицы удобно хранить в одном месте, поэтому кладем их в отдельную папочку:

Так вот пространство внутри базы данных — это та же самая папочка в винде. Место, куда мы сложили свои таблички, чтобы они все были в одном месте.

Пример базы Oracle

Цель та же — выделить отдельное место, чтобы у вас не была одна большая свалка:

заходишь в папку в винде → видишь файлики только из этой папки

заходишь в пространство → видишь только те таблицы, которые в нем есть

Хранение данных в виде табличек — это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички «словно в excel» каждая запись хранится в виде объекта, вот так:

А еще есть файловые базы — когда у вас вся информация хранится в файликах. Да-да, простых текстовых файликах!

Почитать о разных видах баз данных можно в википедии. Я не буду в этой статье углубляться в эту тему, потому что моя задача — объяснить «что это вообще такое» для ребят, которые базу в глаза не видели. А на работе они скорее всего столкнутся именно с реляционной базой данных, поэтому о ней и речь.

Как получить информацию из базы

Нужно записать свой запрос в понятном для базы виде — на SQL. SQL (Structured Query Language) — язык общения с базой данных. В нем есть ключевые слова, которые помогут вам сделать выборку:

select — выбери мне такие-то колонки.

from — из такой-то таблицы базы.

where — такую-то информацию.

Например, я хочу получить информацию по клиенту «Назина Ольга». Составляю в уме ТЗ:

В дословном переводе:

Комментарии в Oracle/PLSQL — мой перевод остается работающим запросом, потому что я убрала «лишнее» в комментарии

Если бы у меня была не база данных, а простые excel-файлики, то же действие было бы:

Открыть файл с нужными данными (clients)

Поставить фильтр на колонку «ФИО» — «Назина Ольга».

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

Бывают запросы и сложнее — когда надо достать данные не из одной таблицы, а из разных. В базе это будет выглядеть даже лучше, чем в эксельке. В экселе вам нужно открыть 1-2-3 таблицы и смотреть в каждую. Неудобно.

А в базе данных вы внутри запроса SQL указываете, какие колонки из каких таблиц вам нужны. И результат запроса их отрисовывает. Скажем, мы хотим увидеть заказ, который сделал клиент, ФИО клиента, и его номер телефона. И всё это в разных таблицах! А мы написали запрос и увидели то, что нам надо:

id_order

order (таблица order)

fio (таблица client)

phone (таблица contacts)

И пусть в таблице клиентов у нас будет 30 колонок, а в таблице заказов 50, в результате выборки мы видим ровно 4 запрошенные. Удобно, ничего лишнего!

Конечно, написать такой запрос будет немного сложнее обычного селекта. Это уже select join, почитать о нем можно тут. И я рекомендую вам его изучить, потому что он входит в «базовое знание sql», которое требуется на собеседованиях.

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

Как связать данные между собой

Вот например, у нас есть интернет-магазин по доставке пиццы. Так выглядит его база данных:

В таблице «client» лежат данные по клиентам: ФИО, пол, дата рождения и т.д.

last_name

first_name

birthdate

В таблице «orders» лежат данные по заказам. Что заказали (пиццу, суши, роллы), когда, насколько довольны доставкой?

order

addr

date

time

Роллы «Филадельфия» и «Канада»

Пицца 35 см, роллы комбо 1

Пицца с сосиками по краям

Комбо набор 3, обед №4

Но как понять, где чей был заказ? Сколько раз заказывал Вася, а сколько Алина?

Тут есть несколько вариантов:

1. Запихать все данные в одну таблицу: тут и заказы, и информация по клиентам. В целом удобно, открыл табличку и сразу видишь — ага, это Васин заказ, а это Машин.

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

Поиск будет работать медленнее. Чем меньше информации в таблице, тем быстрее поиск. Когда у нас много строк, количество колонок становится существенным.

Много дублей — один человек может сделать хоть сотню заказов. И вся информация по нему будет продублирована сто раз. Неоптимальненько!

Чтобы избежать дублей, таблицы принято разделять:

Новые объекты отдельно

Но надо при этом их как-то связать между собой, мы ведь всё еще хотим знать, чей конкретно был заказ. Для связи таблиц используется foreign key, внешний ключ.

Нам надо у заказа сделать отметку о клиенте. Значит, таблица «orders» будет ссылаться на таблицу «clients». Ключ можно поставить на любую колонку таблицы (в некоторых базах колонка должна быть уникальной, сначала её нужно такой указать). Какую бы выбрать?

Можно ссылаться на имя. А что, миленько, в таблице заказов будем сразу имя видеть! Но минуточку. А если у нас два клиента Ивана? Или три Маши? Десять Саш. Ну вы поняли =) И как тогда разобраться, где какой клиент? Не подходит!

Можно вешать foreign key на несколько колонок. Например, на фамилию + имя, или фамилию + имя + отчество. Но ведь и ФИО бывают неуникальные! Что тогда? Можно добавить в связку дату рождения. Тогда шанс ошибиться будет минимален, хотя и такие ребята существуют. И чем больше клиентов у вас будет, тем больше шанс встретить дубликат.

А можно не усложнять! Вместо того, чтобы делать внешний ключ на 10 колонок, лучше создать в таблице клиентов primary key, первичный ключ. Первичный ключ отвечает за то, чтобы каждое значение в поле было уникальным, никаких дублей. При попытке добавить в таблицу запись с неуникальным первичным ключом получаешь ошибку:

Здесь ключ — «id_order»

Вот на него и нужно ссылаться! Обычно таким ключом является ID, идентификатор записи. Его можно сделать автоинкрементальным — это значит, что он генерируется сам по алгоритму «прошлое значение + 1».

Например, у нас гостиница для котиков. Это когда хозяева едут в отпуск, а котика оставить не с кем — оставляем в гостинице!

Источник

§ 2. Работа с таблицами базы данных

Оглавление

2.1. Создание таблиц базы данных

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

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

На основе таблиц создаются другие объекты базы данных.

В процессе создания таблиц можно выделить этапы:

1. Создание объекта Таблица (пример 2.1).

2. Описание структуры таблицы — имен полей, типов и свойств данных в них.

3. Ввод данных в таблицу.

Работать с таблицами баз данных можно в двух режимах (пример 2.2).

Описание структуры таблицы (пример 2.3) выполняется в режиме Конструктор (см. Приложение к главе 1).

Данные в таблицу вводятся в режиме Таблица. В этом режиме можно также просматривать и изменять структуру таблицы.

Таблицы в реляционных базах данных должны обладать следующими свойствами:

1. В таблице не может быть двух записей с полностью совпадающими данными.

2. Поля таблицы должны располагаться в порядке, который определяется при ее создании.

3. В таблице обязательно должно быть хотя бы одно поле.

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

Таблица базы данных похожа на электронную таблицу, и в Access реализована возможность импортировать данные из электронных таблиц в БД (пример 2.4).

Пример 2.1. Создание объекта Таблица в Access.

Пример 2.2. Режимы работы с таблицами в Access.

Пример 2.3. Описание структуры таблицы.

Пример 2.4. Импорт таблицы из Excel в Access.

1. На вкладке Внешние данные выбрать Excel:

2. В окне Внешние данные нажать кнопку .

3. В окне Открытие файла выбрать файл с электронной таблицей и подтвердить выбор.

4. В окне Импорт электронной таблицы на каждом шаге сделать требуемый выбор и нажать кнопку Далее.

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

По завершении нажать кнопку

2.2. Ввод и редактирование данных в таблице

При создании структуры таблицы в режиме Конструктора таблицы (см. Приложение к главе 1) определяются имена полей (пример 2.5) и настраиваются их свойства — тип и формат.

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

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

1. Текстовый. Короткий текст (до 255 символов) и длинный текст.

2. Числовой. Числовые данные (целые или действительные).

3. Дата и время. Дата и/или время.

4. Денежный. Денежные данные, хранящиеся с точностью до 4 десятичных знаков после запятой.

5. Счетчик. Последовательность целых чисел, которые задаются автоматически при вводе записей. Эти числа нельзя изменить.

6. Логический. Может иметь значения Истина или Ложь.

7. Поле объекта OLE. Изображения в формате Точечный рисунок.

8. Гиперссылка. Ссылка на информационный ресурс в Интернете.

9. Вложение. Вложениями могут быть изображения, документы, электронные таблицы, диаграммы и другие файлы.

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

Поле каждого типа имеет свой набор свойств. Наиболее важными являются:

1. Размер поля (пример 2.8), который определяет максимально возможную длину текста или числа.

2. Формат поля, который устанавливает формат данных (пример 2.9).

Обычно одно из полей таблицы при создании структуры определяется как ключевое поле — ключ (пример 2.10).

Ключ (ключевое поле) — поле, значения которого позволяют однозначно определить каждую запись таблицы.

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

Новая таблица состоит из одной пустой записи (пример 2.11). Ввод данных в таблицу базы производится в Режиме таблицы и мало чем отличается от ввода данных в электронную таблицу. При вводе данных пустая запись смещается в конец таблицы (пример 2.12). Отменить ввод значения в поле до перехода к другому полю можно, нажав клавишу Esc или на панели быстрого доступа.

При заполнении таблиц базы данных нужно соблюдать определенные правила:

1. Заполнение таблиц должно производиться по записям.

2. Вводимые данные должны соответствовать заданному при создании структуры таблицы типу. В случае несоответствия появляется предупреждающее сообщение.

Перед редактированием записей таблицы необходимо их выделить. Для этого достаточно выполнить щелчек в поле маркера соответствующей записи (пример 2.13). Отменяется выделение щелчком в любом месте таблицы вне выделения.

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

1. Звездочка. Обозначает пустую запись в конце таблицы.

2. Карандаш. Обозначает, что запись редактируется.

Завершение ввода значений записи осуществляется при переходе к любой другой записи. Access автоматически сохраняет каждую запись по завершении ее обработки.

Для удаления записи необходимо выполнить команду Удалить запись контекстного меню выделенной записи (пример 2.15).

Для быстрого перемещения между записями можно использовать кнопки панели навигации окна таблицы (пример 2.16).

Пример 2.5. Определение имен полей таблицы.

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

Имя не должно начинаться с пробела.

Пример 2.6. Определение типа данных в поле таблицы.

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

Пример 2.7. Тип данных Вложение.

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

Пример 2.8. Свойство Размер поля типа данных Числовой.

Пример 2.9. Свойство Формат поля типа данных Денежный.

Пример 2.10. Определение ключевого поля в структуре таблицы.

Для определения поля как ключевого нужно выбрать кнопку:

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

Пример 2.11. Новая таблица.

Пример 2.12. Заполнение таблицы данными в Access.

При вводе данных к следующей ячейке можно перейти при помощи клавиши Enter либо Tab. В обратном направлении — с помощью комбинации клавиш Shift + Tab. Используя комбинацию клавиш Ctrl + Home, можно перейти в первую ячейку таблицы, Ctrl + End — в последнюю.

Пример 2.13. Выделение записи таблицы.

Пример 2.14. Символы в поле маркера.

Пример 2.15. Удаление записи из таблицы.

Пример 2.16. Панель навигации таблицы базы данных.

2.3. Связывание таблиц базы данных

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

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

1. Один ко многим. Каждой записи в одной таблице могут соответствовать несколько записей в другой таблице.

2. Многие ко многим. Каждой записи в одной таблице могут соответствовать несколько записей в другой таблице и наоборот.

3. Один к одному. Каждой записи в одной таблице может соответствовать только одна запись в другой таблице. Обычно это связь между двумя ключевыми полями.

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

Если после установления связи открыть таблицу, от которой идет связь, то в открывшемся окне видны знаки , расположенные в левой части записей (пример 2.18). Их присутствие говорит о наличии связи ключевого поля таблицы «Города» с другой таблицей. После щелчка на знаке откроется вложенная таблица, содержащая те записи таблицы, значение поля которых равно величине одноименного поля записи таблицы «Города».

Пример 2.17. Создание связи.

1. На вкладке Работа с базами данных выбрать кнопку Схема данных:

Появится диалоговое окно:

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

3. Закрыть окно Добавление таблицы.

4. Перетащить поле связи из одной таблицы на поле связи в другой.

Часто связывают ключевое поле (выделенное полужирным) одной таблицы с аналогичным полем другой таблицы.

Появится окно Изменение связей:

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

5. Задать параметры связи:

6. Нажать кнопку .

Пример 2.18. Просмотр данных в связанных таблицах.

2.4. Сортировка данных в таблице

Записи в таблицах автоматически воспроизводятся отсортированными в порядке возрастания по ключевому полю. При работе с базами данных может возникнуть необходимость сортировки данных по какому-либо полю таблицы в определенном порядке:

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

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

Пример 2.19. Сортировки по полям с различным типом данных.

1. По полю «Кинотеатр» — по алфавиту, в порядке возрастания.

2. По полю «Стоимость» — по значению, в порядке убывания.

3. По полю «Время» — в порядке убывания.

Пример 2.20. Инструменты сортировки вкладки Главная.

Вопросы к параграфу

1. Какой объект баз данных является основным?

2. В каких режимах можно работать с таблицами базы данных?

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

4. В каком режиме работы с таблицами осуществляется ввод данных в таблицу базы данных?

5. Откуда можно импортировать данные в таблицу БД?

6. Какими свойствами должны обладать таблицы БД?

7. Какие типы данных могут быть определены для полей таблицы БД?

8. Что такое ключевое поле таблицы?

9. Как выделить запись? Как удалить запись?

10. Что означают символы звездочка и карандаш, отображаемые в поле маркера?

11. Для чего нужно связывать таблицы?

12. Какие существуют виды связей? Чем они отличаются?

13. Каким образом можно сортировать данные в таблице?

Упражнения

1. Определите типы полей таблицы БД, которая хранит данные об оплате за учебные пособия и содержит поля «Дата», «Номер плательщика», «ФИО», «Наименование учебного заведения», «Номер класса», «Сумма», «Наличие льготы».

2. Определите ключевое поле для таблицы БД, которая хранит данные о выданных аттестатах и включает поля «Фамилия», «Имя», «Отчество», «Дата рождения», «Год выпуска», «Номер аттестата».

3. Выполните перечисленные задания.

1. Создайте базу данных абитуриентов университета, состоящую из двух таблиц.

№	Конструктор	Режим таблицы
1
2

2. Свяжите таблицы по ключу таблицы «Город» и полю «Код города» таблицы «Абитуриенты».
3. Определите, сколько абитуриентов поступало из Минска. Для этого откройте таблицу «Города» и разверните данные вложенной таблицы «Абитуриенты».

4. Откройте базу данных «Аренда автомобилей.accdb». Выполните перечисленные задания.

1. Откройте таблицу «Автомобили» в режиме Конструктор. Запишите в тетрадь список полей с указанием типа данных для каждого поля. Для числовых полей запишите формат представления.
2. В режиме таблицы добавьте в таблицу «Автомобили» записи, как показано на рисунке:

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

Выберите соответствующий файл с изображением.

3. Создайте таблицу «Арендаторы».

Используйте файл «Арендаторы.xlsx» для импортирования данных. Ключ — поле «Код».

4. Создайте таблицу «Аренда».

Конструктор	Режим таблицы

5. Отсортируйте записи в таблице «Автомобили» по возрастанию стоимости.

5. Установите связи вида Один ко многим между таблицами базы данных «Аренда автомобилей.accdb». Обеспечьте целостность связей.

Источник