Что такое структура таблицы базы данных
Общие сведения о таблицах
Таблицы — это неотъемлемая часть любой базы данных, так как именно в них содержатся все сведения и данные. Например, база данных предприятия может содержать таблицу «Контакты», в которой хранятся имена всех поставщиков, их адреса электронной почты и номера телефонов. Так как другие объекты базы данных в значительной степени зависят от таблиц, всегда начинайте разработку базы данных с создания всех таблиц, а уже затем создавайте другие объекты. Перед созданием таблиц проанализируйте свои требования и определите, какие именно таблицы могут вам понадобиться. Начальные сведения о планировании и разработке баз базы данных см. в статье Основные сведения о создании баз данных.
В этой статье
Обзор
Обычно реляционная база данных, такая как Access, состоит из нескольких таблиц. В хорошо спроектированной базе данных в каждой таблице хранятся сведения о конкретном объекте, например о сотрудниках или товарах. Таблица состоит из записей (строк) и полей (столбцов). Поля, в свою очередь, содержат различные типы данных: текст, числа, даты и гиперссылки.
Запись. Содержит конкретные данные, например информацию об определенном работнике или продукте.
Поле. Содержит данные об одном аспекте элемента таблицы, например имя или адрес электронной почты.
Свойства таблиц и полей
У таблиц и полей также есть свойства, которые позволяют управлять их характеристиками и работой.
1. Свойства таблицы
В базе данных Access свойствами таблицы называются атрибуты, определяющие ее внешний вид и работу. Свойства таблицы задаются на странице свойств таблицы в Конструкторе. Например, вы можете задать для таблицы свойство Режим по умолчанию, чтобы указать, как она должна отображаться по умолчанию.
Свойство поля применяется к определенному полю в таблице и определяет его характеристики или определенный аспект поведения. Некоторые свойства поля можно задать в Режим таблицы. Вы также можете настраивать любые свойства в Конструкторе с помощью области Свойства поля.
Типы данных
У каждого поля есть тип данных. Тип данных поля определяет данные, которые могут в нем храниться (например, большие объемы текста или вложенные файлы).
Тип данных является свойством поля, однако он отличается от других свойств:
Тип данных поля задается на бланке таблицы, а не в области Свойства поля.
Тип данных определяет, какие другие свойства есть у этого поля.
Тип данных необходимо указывать при создании поля.
Чтобы создать новое поле в Access, введите данные в новый столбец в режиме таблицы. В таком случае Access автоматически определяет тип данных для поля в зависимости от введенного значения. Если оно не относится к определенному типу, Access выбирает текстовый тип. При необходимости его можно изменить с помощью ленты.
Примеры автоматического определения типа данных
Ниже показано, как выполняется автоматическое определение типа данных в режиме таблицы.
Тип данных для поля, назначаемый Access
Вы можете использовать любой допустимый префикс протокола IP. Например, являются допустимыми префиксы http://, https:// и mailto:.
Число, длинное целое
Число, длинное целое
Распознаваемые форматы даты и времени зависят от языкового стандарта.
Распознаваемое обозначение денежной единицы зависит от языкового стандарта.
Отношения между таблицами
Хотя в каждой из таблиц хранятся данные по отдельному объекту, в базе данных Access все они обычно связаны между собой. Ниже приведены примеры таблиц в базе данных.
Таблица клиентов, содержащая сведения о клиентах компании и их адреса.
Таблица продаваемых товаров, включающая цены и изображения каждого из них.
Таблица заказов, служащая для отслеживания заказов клиентов.
Так как данные по разным темам хранятся в отдельных таблицах, их необходимо как-то связать, чтобы можно было легко комбинировать данные из разных таблиц. Для этого используются связи. Связь — это логическое отношение между двумя таблицами, основанное на их общих полях. Дополнительные сведения см. в статье Руководство по связям между таблицами.
Ключи
Поля, формирующие связь между таблицами, называются ключами. Ключ обычно состоит из одного поля, однако может включать и несколько. Есть два вида ключей.
Первичный ключ. В таблице может быть только один первичный ключ. Он состоит из одного или нескольких полей, однозначно определяющих каждую запись в этой таблице. Часто в качестве первичного ключа используется уникальный идентификатор, порядковый номер или код. Например, в таблице «Клиенты» каждому клиенту может быть назначен уникальный код клиента. Поле кода клиента является первичным ключом этой таблицы. Если первичный ключ состоит из нескольких полей, он обычно включает уже существующие поля, формирующие в сочетании друг с другом уникальные значения. Например, в таблице с данными о людях в качестве первичного ключа можно использовать сочетание фамилии, имени и даты рождения. Дополнительные сведения см. в статье Добавление и изменение первичного ключа таблицы.
Внешний ключ. В таблице также может быть один или несколько внешних ключей. Внешний ключ содержит значения, соответствующие значениям первичного ключа другой таблицы. Например, в таблице «Заказы» каждый заказ может включать код клиента, соответствующий определенной записи в таблице «Клиенты». Поле «Код клиента» является внешним ключом таблицы «Заказы».
Соответствие значений между полями ключей является основой связи между таблицами. С помощью связи между таблицами можно комбинировать данные из связанных таблиц. Предположим, есть таблицы «Заказчики» и «Заказы». В таблице «Заказчики» каждая запись идентифицируется полем первичного ключа — «Код».
Чтобы связать каждый заказ с клиентом, вы можете добавить в таблицу «Заказы» поле внешнего ключа, соответствующее полю «Код» в таблице «Заказчики», а затем создать связь между этими двумя ключами. При добавлении записи в таблицу «Заказы» можно было бы использовать значение кода клиента из таблицы «Заказчики». При просмотре каких-либо данных о клиенте, сделавшем заказ, связь позволяла бы определить, какие данные из таблицы «Заказчики» соответствуют тем или иным записям в таблице «Заказы».
1. Первичный ключ, который определяется по значку ключа рядом с именем поля.
2. Внешний ключ (определяется по отсутствию значка ключа)
Если ожидается, что для каждого представленного в таблице уникального объекта потребуется несколько значений поля, такое поле добавлять не следует. Обратимся к приведенному выше примеру: если нужно отслеживать размещенные клиентами заказы, не следует добавлять поле в таблицу, поскольку у каждого клиента будет несколько заказов. Вместо этого создается новая таблица для хранения заказов, а затем создаются связи между этими двумя таблицами.
Преимущества использования связей
Раздельное хранение данных в связанных таблицах обеспечивает указанные ниже преимущества.
Связи между таблицами необходимо иметь в виду еще на этапе планирования таблиц. С помощью мастера подстановок можно создать поле внешнего ключа, если таблица с соответствующим первичным ключом уже существует. Мастер подстановок помогает создать связь. Дополнительные сведения см. в статье Создание и удаление поля подстановки.
Урок 1. Введение в базы данных
Что такое база данных
Структура базы данных
Рис.1.1. Таблица, запись и поле.
В отличие от плоских, реляционные базы данных состоят из нескольких таблиц, связь между которыми устанавливается с помощью совпадающих значений одноименных полей.
Здесь следует отметить, что использование реляционной модели баз данных не является единственно возможным способом представления информации. В настоящее время существует несколько различных моделей представления данных, которые, однако, пока не получили такого широкого распространения среди разработчиков и пользователей, как реляционная модель. То есть при разработке систем управления базами данных реляционная модель практически является стандартом.
В качестве примера реляционной базы данных можно привести поставляемую вместе с Visual Basic базу данных BIBLIO.MDB, содержащую библиографическую информацию о книгах по программированию, их авторах и издательствах, эти книги опубликовавших.
Так как Visual Basic использует ту же систему управления базами данных (MS Jet Engine), что и MS Access, то несмотря на наличие в Visual Basic средств работы со многими форматами БД, все таки в приложениях предпочтительно использовать файлы баз данных в формате MS Access. Эти файлы имеют расширение MDB и здесь в основном будут описаны приемы работы с файлами именно такого формата.
Перейдем теперь к исследованию базы данных с библиографией. Для этого откройте файл BIBLIO.MDB при помощи MS Access или VisData.
Содержимое файла базы данных BIBLIO.MDB показано на рис.1.2. В базу данных входят таблицы (Tables), запросы (Queries), формы (Forms), отчеты (Reports), макросы (Macros) и модули (Modules). Макросы, формы и модули нам не интересны, так как это вотчина разработчиков, применяющих Visual Basic for Applications или, сокращенно, VBA.
Рис.1.2. Содержимое файла BIBLIO.MDB
Из рисунка видно, что база данных состоит из таблиц: PUBLISHERS, AUTHORS и TITLES. Каждая из таблиц содержит информацию об объектах одного типа. Из названий таблиц становиться понятно, что данные в каждой таблице принадлежат одной и той же группе объектов. Каждая строка в этих таблицах однозначно определяет один объект из соответствующей группы. Вообще, база данных может состоять из одной или нескольких таблиц. Запись, в свою очередь, состоит из нескольких полей, каждое из которых содержит элемент данных об объекте.
Типы данных, которые можно поместить в таблицу, зависят от формата файла базы данных. В таблице 1.1 приведены некоторые типы данных, которые поддерживаются системой управления базами данных Visual Basic для файлов MS Access.
Таблица 1.1
Таблица PUBLISHERS (Издатели) содержит информацию об издательствах (имя компании, ее адрес, телефон, факс и др.). На рис. 1.3 и 1.4 показаны структура таблицы PUBLISHERS и ее содержимое в табличном виде.
Рис.1.3. Структура таблицы PUBLISHERS 
Рис.1.4. Содержимое таблицы PUBLISHERS
Рис.1.5. Структура таблицы AUTHORS 
Рис.1.6. Содержимое таблицы AUTHORS
Рис.1.7. Структура таблицы TITLES 
Рис.1.8. Содержимое таблицы TITLES
Из рис.1.2 видно, что в базе данных BIBLIO.MDB присутствует еще и таблица TITLE AUTHOR. На первый взгляд непонятно зачем она нужна. Ведь в базе данных есть таблица TITLES с заголовками книг и таблица AUTHORS с данными об авторах. Однако все же эта таблица нужна и для чего она так необходима станет понятно, когда в дальнейшем будем рассматривать отношения между таблицами.
Отношения между таблицами
Отношения между таблицами устанавливают связь между данными находящимися в разных таблицах базы данных.
Отношения между таблицами определяются отношением между группами объектов соответствующего типа. Например, один автор может написать несколько книг и издать их в разных издательствах. Или издательство может опубликовать несколько книг разных авторов. Таким образом, между авторами и названиями книг существует отношение один-ко-многим, а между издательствами и авторами существует отношение много-ко-многим.
Отношения между таблицами базы данных BIBLIO.MDB показаны на рис.1.9.
Рис.1.9. Отношения между таблицами базы данных BIBLIO.MDB.
Отношение один-к-одному
Если между двумя таблицами существует отношение один-к-одному, то это означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице.
Рис.1.10. Структура таблицы PERSON
Между таблицами AUTHORS и PERSON существует отношение один-к-одному, так как одна запись, идентифицирующая автора, однозначно соответствует только одной записи в таблице PERSON, содержащей персональные данные об авторе.
Связь между таблицами определяется с помощью совпадающих полей: Au_ID в таблице AUTHORS и в таблице PERSON.
Отношение один-ко-многим
Хорошим примером отношения между таблицами один-ко-многим является отношение между авторами и названиями книг (таблицы AUTHORS и TITLES), так как каждый автор может иметь отношение к созданию нескольких книг. Связь между таблицами AUTHORS и TITLES осуществляется с помощью совпадающих полей Au_ID в обеих таблицах.
Аналогичное отношение существует между издательствами и названиями изданных книг, организацией и работающими в ней сотрудниками, автомобилем и деталями, из которых он состоит и т.п. Понятно, что подобный тип отношения между таблицами наиболее часто встречается при проектировании структуры баз данных.
Отношение много-к-одному
Отношение много-к-одному полностью аналогично рассмотренному выше отношению один-ко-многим.
Отношение много-ко-многим
Для удобства работы с таблицами, имеющими отношение много-ко-многим, обычно в базу данных добавляют еще одну таблицу, которая находится в отношении один-ко-многим и много-к-одному к соответствующим таблицам. В случае базы данных BIBLIO.MDB такой таблицей является TITLE AUTHOR.
Нормализация баз данных
Рассмотрим процесс нормализации базы данных на примере базы данных BIBLIO.MDB. Вообще говоря, все данные о книгах, авторах и издательствах можно разместить в одной таблице, названной, например, BIBLIOS. Структура этой таблицы показана на рис. 1.11. В принципе, можно работать и с такой таблицей. С другой стороны понятно, что такая структура данных является неэффективной. В таблице BIBLIOS будет достаточно много повторяющихся данных, например сведения об издательстве или авторе будут повторяться для каждой опубликованной книги. Такая организация данных приведет к следующим проблемам, с которыми столкнется конечный пользователь вашей программы:
Наличие повторяющихся данных приведет к неоправданному увеличению размера файла базы данных. Кроме нерационального использования дискового пространства, это также вызовет заметное замедление работы приложения.
Ввод пользователем большого количества повторяющейся информации неизбежно приведет к возникновению ошибок.
Изменение, например, номера телефона издательства потребует значительных усилий по корректировке каждой записи, содержащей данные об издателе.
Если, при проектировании приложения для работы с базами данных, вы организуете свои данные таким нерациональным образом, то в дальнейшем вам, скорее всего, больше не поручат решение аналогичных задач.
Чтобы избежать всех этих проблем, надо стремиться максимально уменьшить количество повторяющейся информации. Процесс уменьшения избыточности информации в базе данных посредством разделения ее на несколько связанных друг с другом таблиц и называется нормализацией данных.
Вообще говоря, существует строгая теория нормализации данных, в рамках которой разработаны алгоритмы уменьшения избыточности информации, определены несколько уровней нормализации и установлены критерии, определяющие соответствие данных определенному уровню нормализации. Знакомство с теорией нормализации данных выходит за рамки этих уроков и тем читателям, которым интересно побольше узнать об этом, можно посоветовать обратиться к специальной литературе.
Для того, чтобы построить достаточно эффективную структуру данных, достаточно придерживаться нескольких простых правил:
1. Определите таблицы таким образом, чтобы записи в каждой таблице описывали объекты одного и того же типа. В нашем случае библиографические данные можно разместить в трех таблицах:
2. Если в вашей таблице появляются поля, содержащие аналогичные данные, разделите таблицу.
3. Не запоминайте в таблице данных, которые могут быть вычислены при помощи данных из других таблиц.
4. Используйте вспомогательные таблицы. Например, если в вашей таблице есть поле Страна, то может быть стоит ввести вспомогательную таблицу Country, которая будет содержать соответствующие записи (Россия, Украина, США и т.п.). Этот прием также поможет уменьшить количество ошибок при вводе данных, допускаемых пользователями.
Ключи и индексы
Как было отмечено выше при описании отношений между таблицами, в реляционных базах данных таблицы связываются друг с другом посредством совпадающих значений ключевых полей. Ключевым полем может быть практически любое поле в таблице. Ключ может быть первичным (primary) или внешним (foreign).
Первичный ключ однозначно определяет запись в таблице. В примере с базой данных BIBLIO.MDB таблицы PUBLISHERS, AUTHORS и TITLES имеют первичные ключи PubID, Au_ID и ISBN соответственно. Таблица TITLES также имеет два внешних ключа PubID и Au_ID для связи с таблицами PUBLISHERS и AUTHORS. Таким образом, первичный ключ однозначно определяет запись в таблице, в то время как внешний ключ используется для связи с первичным ключом другой таблицы.
Ключевой поле может иметь определенный смысл, как например ключ ISBN в таблице TITLES. Однако, очень часто ключевое поле не несет никакой смысловой нагрузки и является просто идентификатором объекта в таблице. Во многих случаях удобно использовать в качестве ключа поле счетчика (Counter field). При этом вся ответственность по поддержанию уникальности ключевого поля снимается с пользователя и перекладывается на процессор баз данных. Поле счетчика представляет собой четырехбайтовое целое число (Long) и автоматически увеличивается на единицу при добавлении пользователем новой записи в таблицу.
Данные запоминаются в таблице в том порядке, в котором они вводятся пользователем. Это, так называемый, физический порядок следования записей. Однако, часто требуется представить данные в другом, отличном от физического, порядке. Например может потребоваться просмотреть данные об авторах книг, упорядоченные по алфавиту. Кроме того, часто необходимо найти в большом объеме информации запись, удовлетворяющую определенному критерию. Простой перебор записей при поиске в большой таблице может потребовать достаточно много времени и поэтому будет неэффективным.
Одними из основных требований, предъявляемым к системам управления базами данных, являются возможность представления данных в определенном, отличном от физического, порядке и возможность быстрого поиска определенной записи. Эффективным средством решения этих задач является использование индексов.
Индекс представляет собой таблицу, которая содержит ключевые значения для каждой записи в таблице данных и записанные в порядке, требуемом для пользователя. Ключевые значения определяются на основе одного или нескольких полей таблицы. Кроме того, индекс содержит уникальные ссылки на соответствующие записи в таблице. На рис.1.12 показан фрагмент таблицы CUSTOMERS, содержащей информацию о покупателях, и индекс IDX_NAME, построенный на основе поля Name таблицы CUSTOMERS. Индекс IDX_NAME содержит значения ключевого поля Name, упорядоченные в алфавитном порядке, и ссылки на соответствующие записи в таблице CUSTOMERS.
Рис.1.12. Связь между таблицей и индексом.
Каждая таблица может иметь несколько различных индексов, каждый из которых определяет свой собственный порядок следования записей. Например, таблица AUTHORS может иметь индексы для представления данных об авторах, упорядоченные по дате рождения или по алфавиту. Таким образом, каждый индекс используется для представления одних и тех же данных, но упорядоченных различным образом.
Вообще говоря, таблицы в базе данных могут и не иметь индексов. В этом случае для большой таблицы время поиска определенной записи может быть весьма значительным и использование индекса становиться необходимым. С другой стороны, не следует увлекаться созданием слишком большого количества индексов, так как это может заметно увеличить время необходимое для обновления базы данных и значительно увеличить размер файла базы данных.
При разработке приложений, работающих с базами данных, наиболее широко используются простые индексы. Простые индексы используют значения одного поля таблицы. Примером простого индекса в базе данных BIBLIO.MDB может служить код ISBN, идентификатор автора Au_ID или идентификатор издательства PubID.
Хотя в большинстве случаев для представления данных в определенном порядке достаточно использовать простой индекс, часто возникают ситуации, где не обойтись без использования составных индексов. Составной индекс строится на основе значений двух или более полей таблицы. Хорошей иллюстрацией использования составных индексов может служить база данных родственников при генеалогических исследованиях какой-либо фамилии. Понятно, что использование в качестве простого индекса фамилии человека в данном случае недопустимо. Даже использование составного индекса, основанного на полях имени, фамилии и отчества может быть неэффективным, так как и в этом случае все равно возможно существование достаточно большого числа однофамильцев. Выходом из положения может быть использование составного индекса, основанного, например, на следующих полях таблицы: имя, фамилия, отчество, город и номер телефона.
Структура таблицы БД и типы данных
Основным структурным компонентом БД является таблица. Каждая запись таблицы содержит всю необходимую информацию об отдельном элементе базы данных. Например, запись о сотруднике может содержать фамилию, имя, отчество, дату рождения, должность и т.п.
Структура таблицы определяется:
• названиями полей, из которых она состоит,
Каждому полю таблицы присваивается уникальное имя (название), которое может содержать не более 64 символов (нельзя использовать символы !, .,%, $,#) и задаётся один из основных типов данных. Значение типа поля может быть задано только в режиме конструктора.
В табл. 1. представлены типы данных Access и их описание.
создание пустой таблицы в MS Access 2010 возможно двумя способами:
1 Режим таблицы. Ввод данных непосредственно в пустую таблицу с добавлением новых полей и типов данных в них;
2 Режим конструктора. Определение всех параметров макета таблицы.
Основным является Режим конструктора, он позволяет не только создавать пустую таблицу, определять все параметры её макета, но и изменять таблицы, созданные другими методами (с помощью мастера БД, мастера таблиц и в режиме таблицы) – изменять и добавлять поля, устанавливать значения по умолчанию, ограничения, маски ввода и др.
Запуск MS Access производится через кнопку Пуск \ Все программы\ Microsoft Office \ Microsoft Access 2010, в результате появляется окно приложения (рисунок 1.1)
Рисунок 1.1 Окно приложения MS Office 2010
После ввода имени будущей БД в поле «Имя файла» вместо «База данных1» и щелчка по кнопке Создать откроется окно создания таблицы БД (рисунок 1.2). В левом части окна в области переходов (поле Все объекты Access) в разделе Таблицы появится значок таблицы с именем Таблица1.
Рисунок 1.2 Окно создания таблицы БД
Таблица в СУБД Access создаётся в два этапа:
2 этап – в режиме Таблица строки таблицы с готовыми полями (столбцами) построчно заполняются данными. Строки в таблицах БД называются записями.
Для перехода в режим Конструктор нужно либо щелкнуть во вкладке Главная, раздел Режимы по кнопке Режимы и выбрать режим Конструктор, либо щелкнуть правой мышью по значку таблицы и в контекстном меню выбрать команду Конструктор. На рисунке 1.3 в режиме Конструктор введены названия полей и их типы данных.
Рисунок 1.3 Режим Конструктор
После создания структуры таблицы выбираем режим Таблица в разделе Режимы и заполняем её данными. Перед этим MS Acess предлагает сохранить таблицу под другим именем.