что составляет структуру таблицы в бд
Руководство по разработке структуры и проектированию базы данных
Этапы создания базы данных
Надлежащим образом структурированная база данных:
Основные этапы разработки базы данных:
Анализ требований: определение цели базы данных
Вот несколько способов сбора информации перед созданием базы данных:
Начните со сбора существующих данных, которые будут включены в базу. Затем определите типы данных, которые нужно сохранить. А также объекты, которые описывают эти данные. Например:
Структура базы данных: построение блоков
Чтобы преобразовать списки данных в таблицы, начните с создания таблицы для каждого типа объектов, таких как товары, продажи, клиенты и заказы. Вот пример:
Каждая строка таблицы называется записью. Записи включают в себя информацию о чем-то или о ком-то, например, о конкретном клиенте. Столбцы (также называемые полями или атрибутами) содержат информацию одного типа, которая отображается для каждой записи, например, адреса всех клиентов, перечисленных в таблице.
Чтобы при проектировании модели базы данных обеспечить согласованность разных записей, назначьте соответствующий тип данных для каждого столбца. К общим типам данных относятся:
В визуальном представлении БД каждая таблица будет представлена блоком на диаграмме. В заголовке каждого блока должно быть указано, что описывают данные в этой таблице, а ниже должны быть перечислены атрибуты:
При проектировании информационной базы данных необходимо решить, какие атрибуты будут служить в качестве первичного ключа для каждой таблицы, если таковые будут. Первичный ключ ( PK ) — это уникальный идентификатор для данного объекта. С его помощью вы можете выбрать данные конкретного клиента, даже если знаете только это значение.
Атрибуты, выбранные в качестве первичных ключей, должны быть уникальными, неизменяемыми и для них не может быть задано значение NULL ( они не могут быть пустыми ). По этой причине номера заказов и имена пользователей являются подходящими первичными ключами, а номера телефонов или адреса — нет. Также можно использовать в качестве первичного ключа несколько полей одновременно ( это называется составным ключом ).
Создание связей между сущностями
Теперь, когда данные преобразованы в таблицы, нужно проанализировать связи между ними. Сложность базы данных определяется количеством элементов, взаимодействующих между двумя связанными таблицами. Определение сложности помогает убедиться, что вы разделили данные на таблицы наиболее эффективно.
Каждый объект может быть взаимосвязан с другим с помощью одного из трех типов связи:
Связь «один-к одному»
Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь « один-к одному » ( часто обозначается 1:1 ). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:
Если при проектировании и разработке баз данных у вас нет оснований разделять эти данные, связь 1:1 обычно указывает на то, что в лучше объединить эти таблицы в одну.
Чтобы гарантировать, что данные соотносятся правильно, в нужно будет включить, по крайней мере, один идентичный столбец в каждой таблице. Скорее всего, это будет первичный ключ.
Связь «один-ко-многим»
Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи « один- ко-многим » ( 1:M ) обозначаются так называемой «меткой ноги вороны», как в этом примере:
Связь «многие-ко-многим»
Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь « многие-ко-многим » ( M:N ). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.
На ER-диаграмме эти связи отображаются с помощью следующих строк:
При проектировании структуры базы данных реализовать такого рода связи невозможно. Вместо этого нужно разбить их на две связи « один-ко-многим ».
Каждая запись в таблице связей будет соответствовать двум сущностям из соседних таблиц. Например, таблица связей между студентами и курсами может выглядеть следующим образом:
Обязательно или нет?
Другим способом анализа связей является рассмотрение того, какая сторона связи должна существовать, чтобы существовала другая. Необязательная сторона может быть отмечена кружком на линии. Например, страна должна существовать для того, чтобы иметь представителя в Организации Объединенных Наций, а не наоборот:
Два объекта могут быть взаимозависимыми ( один не может существовать без другого ).
Рекурсивные связи
Иногда при проектировании базы данных таблица указывает на себя саму. Например, таблица сотрудников может иметь атрибут «руководитель», который ссылается на другое лицо в этой же таблице. Это называется рекурсивными связями.
Лишние связи
Лишние связи — это те, которые выражены более одного раза. Как правило, можно удалить одну из таких связей без потери какой-либо важной информации. Например, если объект « ученики » имеет прямую связь с другим объектом, называемым « учителя », но также имеет косвенные отношения с учителями через « предметы », нужно удалить связь между « учениками » и « учителями ». Так как единственный способ, которым ученикам назначают учителей — это предметы.
Нормализация базы данных
После предварительного проектирования базы данных можно применить правила нормализации, чтобы убедиться, что таблицы структурированы правильно.
В то же время не все базы данных необходимо нормализовать. В целом, базы с обработкой транзакций в реальном времени ( OLTP ), должны быть нормализованы.
Базы данных с интерактивной аналитической обработкой ( OLAP ), позволяющие проще и быстрее выполнять анализ данных, могут быть более эффективными с определенной степенью денормализации. Основным критерием здесь является скорость вычислений. Каждая форма или уровень нормализации включает правила, связанные с нижними формами.
Первая форма нормализации
Первая форма нормализации ( сокращенно 1NF ) гласит, что во время логического проектирования базы данных каждая ячейка в таблице может иметь только одно значение, а не список значений. Поэтому таблица, подобная той, которая приведена ниже, не соответствует 1NF :
Возможно, у вас возникнет желание обойти это ограничение, разделив данные на дополнительные столбцы. Но это также противоречит правилам: таблица с группами повторяющихся или тесно связанных атрибутов не соответствует первой форме нормализации. Например, приведенная ниже таблица не соответствует 1NF :
Вместо этого во время физического проектирования базы данных разделите данные на несколько таблиц или записей, пока каждая ячейка не будет содержать только одно значение, и дополнительных столбцов не будет. Такие данные считаются разбитыми до наименьшего полезного размера. В приведенной выше таблице можно создать дополнительную таблицу « Реквизиты продаж », которая будет соответствовать конкретным продуктам с продажами. « Продажи » будут иметь связь 1:M с « Реквизитами продаж ».
Вторая форма нормализации
Вторая форма нормализации ( 2NF ) предусматривает, что каждый из атрибутов должен полностью зависеть от первичного ключа. Каждый атрибут должен напрямую зависеть от всего первичного ключа, а не косвенно через другой атрибут.
Например, атрибут « возраст » зависит от « дня рождения », который, в свою очередь, зависит от « ID студента », имеет частичную функциональную зависимость. Таблица, содержащая эти атрибуты, не будет соответствовать второй форме нормализации.
Кроме этого таблица с первичным ключом, состоящим из нескольких полей, нарушает вторую форму нормализации, если одно или несколько полей не зависят от каждой части ключа.
Таким образом, таблица с этими полями не будет соответствовать второй форме нормализации, поскольку атрибут « название товара » зависит от идентификатора продукта, но не от номера заказа:
Третья форма нормализации
Третья форма нормализации ( 3NF ) : каждый не ключевой столбец должен быть независим от любого другого столбца. Если при проектировании реляционной базы данных изменение значения в одном не ключевом столбце вызывает изменение другого значения, эта таблица не соответствует третьей форме нормализации.
Многомерные данные
Некоторым пользователям может потребоваться доступ к нескольким разрезам одного типа данных, особенно в базах данных OLAP. Например, им может потребоваться узнать продажи по клиенту, стране и месяцу. В этой ситуации лучше создать центральную таблицу, на которую могут ссылаться таблицы клиентов, стран и месяцев. Например:
Правила целостности данных
Правило целостности ссылок требует, чтобы каждый внешний ключ, указанный в одной таблице, сопоставлялся с одним первичным ключом в таблице, на которую он ссылается. Если первичный ключ изменяется или удаляется, эти изменения необходимо реализовать во всех объектах, на которые ссылается этот ключ в базе данных.
Правила целостности бизнес-логики обеспечивают соответствие данных определенным логическим параметрам. Например, время встречи должно быть в пределах стандартных рабочих часов.
Добавление индексов и представлений
Индекс — это отсортированная копия одного или нескольких столбцов со значениями в возрастающем или убывающем порядке. Добавление индекса позволяет быстрее находить записи. Вместо повторной сортировки для каждого запроса система может обращаться к записям в порядке, указанном индексом.
Хотя индексы ускоряют извлечение данных, они могут замедлять добавление, обновление и удаление данных, поскольку индекс нужно перестраивать всякий раз, когда изменяется запись.
Представление — это сохраненный запрос данных. Представления могут включать в себя данные из нескольких таблиц или отображать часть таблицы.
Расширенные свойства
После того как схема базы данных будет готова можно уточнить БД с помощью расширенных свойств, таких как справочный текст, маски ввода и правила форматирования, которые применяются к конкретной схеме, представлению или столбцу. Преимущество этого метода заключается в том, что, поскольку эти правила хранятся в самой базе, представление данных будет согласовано между несколькими программами, которые обращаются к данным.
SQL и UML
Унифицированный язык моделирования ( UML ) — это еще один визуальный способ выражения сложных систем, созданных на объектно-ориентированном языке. Некоторые из концепций, упомянутых в этом руководстве, известны в UML под разными названиями. Например, объект в UML известен, как класс.
Сейчас UML используется не так часто. В наши дни он применяется академически и в общении между разработчиками программного обеспечения и их клиентами.
Системы управления базами данных
Проектируемая структура базы данных зависит от того, какую СУБД вы используете. Некоторые из наиболее распространенных:
Подходящую систему управления базами данных можно выбирать исходя из стоимости, установленной операционной системы, наличия различных функций и т. д.
Пожалуйста, опубликуйте свои мнения по текущей теме материала. За комментарии, дизлайки, подписки, лайки, отклики низкий вам поклон!
Пожалуйста, оставляйте свои мнения по текущей теме материала. За комментарии, подписки, отклики, лайки, дизлайки низкий вам поклон!
§ 2. Работа с таблицами базы данных
| Сайт: | Профильное обучение |
| Курс: | Информационные технологии. 10 класс (Базовый уровень) |
| Книга: | § 2. Работа с таблицами базы данных |
| Напечатано:: | Гость |
| Дата: | Воскресенье, 28 Ноябрь 2021, 17:45 |
Оглавление
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. Инструменты сортировки вкладки Главная.
