какие существуют типы информационных связей опишите каждый тип

Типы связей информационных объектов

Одно – однозначные связи

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

Рис.1 Графическое изображение одно – однозначных отношений объектов

Одно – многозначные связи (1:М)

Одно – многозначные связи (1:М) – это такие связи, когда экземпляру одного объекта (А) может соответствовать несколько экземпляров другого объекта (В), а каждому экземпляра второго объекта (В) может соответствовать только один экземпляр первого объекта (А).

Рис.2 Графическое изображение одно – многозначный связи отношений объектов.

В такой связи объект А является главным объектом, а объект В – подчиненным, т.е. имеет место иерархическая подчиненность объекта В объекту А. Примером одно – многозначных связей являются подразделения – сотрудники, кафедра – преподаватель, группа студент и т.п.

Много – многозначные связи (M:N)

Много – многозначные связи (M:N) – это когда, каждому экземпляру одного объекта (А) могут соответствовать несколько экземпляров второго объекта (В) и наоборот, каждому экземпляру второго объекта (В) может соответствовать тоже несколько экземпляров первого объекта (А).

Рис.3 Преобразование связи типа M:N через объект – связку

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

Определение связей между информационными объектами

Таблица 1. Объекты справочной информации о студентах, группах и предметах

Таблица 2. Группировка реквизитов по информационным объектам документа Список преподавателей кафедры

В таблице приняты обозначения для ключа: П – простой, У – уникальный.

Рис.4 Много – многозначные связи информационных объектов

Рис.5 Информационно – логическая модель предметной области Учебный процесс

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

Таблица 3 Связи информационных объектов

Информационно – логическая модель предметной области Учебный процесс

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

Логическая структура реляционной базы данных

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

Связи между объектами модели данных реализуются одинаковыми реквизитами – ключами связи в соответствующих таблицах. При этом ключом связи всегда является уникальный ключ главной таблицы. Ключом связи в подчиненной таблице является либо некоторая часть уникального ключа в ней, либо поле, не входящее в состав первичного ключа (например, код кафедры в таблице ПРЕПОДАВАТЕЛЬ ). Ключ связи в подчиненной таблице называется внешним ключом. В Access может быть создана схема данных, наглядно отображающая логическую структуру базы данных. Определение одно – многозначных связей в этой схеме должно осуществляться в соответствии с построенной моделью данных. Внешний вид схемы данных практически совпадает с графическим представлением информационно – логической модели. Для модели данных, построенной в рассмотренном примере, логическая структура базы данных в виде схемы данных Access приведена на рис.2.7.

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

Источник

Система управления базами данных SQLite. Изучаем язык запросов SQL и реляционные базы данных на примере библиотекой SQLite3. Курс для начинающих.

Часть 3.2: Виды связей между таблицами в базе данных. Связи в реляционных базах данных. Отношения, кортежи, атрибуты

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. Продолжаем изучать теорию реляционных баз данных и в этой части мы познакомимся с видами и типами связей между таблицами в реляционных базах данных. Так же мы познакомимся с такими термина, как: кортеж, атрибут и отношения. Данная тема является базовой и ее понимание необходимо для работы с базами данных и для их проектирования.

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

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

Термины кортеж, атрибут и отношение в реляционных базах данных

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

Таблица с данными из базы данных World

У нас есть простая таблица City из базы данных World, в которой есть строки и столбцы. Но термины: таблица, строка, столбец – это термины стандарта SQL.
Кстати: ни одна из существующих в мире СУБД не имеет полной поддержки того или иного стандарта SQL, но и ни один стандарт SQL полностью не реализует математику реляционных баз данных.
В терминологии реляционных баз данных: таблица – это отношение (принимается такое допущение), строка – это кортеж, а столбец – атрибут. Иногда вы можете услышать, как некоторые разработчики называют строки записями. Чтобы не было путаницы в дальнейшем предлагаю использовать термины SQL.
Если рассматривать таблицу, как объект (например книга), то столбец – это характеристики объекта, а строки содержат информацию об объекте.

Виды и типы связей между таблицами в реляционных базах данных

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

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

Связь один ко многим в реляционных базах данных реализуется тогда, когда объекту А может принадлежать или же соответствовать несколько объектов Б, но объекту Б может соответствовать только один объект А. Не совсем понятно, поэтому смотрим пример ниже.

Реализация связи один ко многим в реляционных базах данных

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

Связь многие ко многим

Связь многие ко многим реализуется в том случае, когда нескольким объектам из таблицы А может соответствовать несколько объектов из таблицы Б, и в тоже время нескольким объектам из таблицы Б соответствует несколько объектов из таблицы А. Рассмотрим простой пример.

Пример связи многие ко многим

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

Связь один к одному

Связь один к одному – самая редко встречаемая связь между таблицами. В 97 случаях из 100, если вы видите такую связь, вам необходимо объединить две таблицы в одну.

Пример связи один к одному

Таблицы будут связаны один к одному тогда, когда одному объекту таблицы А соответствует один объект таблицы Б, и одному объекту таблицы Б соответствует один объект таблицы А. Как я уже говорил: если вы видите, что связь один к одному – смело объединяйте таблицы в одну, за исключением тех случаев, когда происходит модернизация базы данных.
Например, у нас была таблица, в которой хранились данные о сотрудниках компании. Но произошли какие-то изменения в бизнес-процессе и появилась необходимость создать таблицы с теми же самыми сотрудниками, но не для всей компании, а разбив их по отделам. Таблицы отделов будут дочерними по отношению к таблице, в которой хранятся данные обо всех сотрудниках компании, и связаны такие таблицы будут связью один к одному.

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

Источник

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

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. Задачи

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

Источник

Типы связей информационных объектов

Связи информационных объектов могут быть разного типа: одно-однозначные (1:1); одно-многозначные (1:М); много-многозначные (M:N).

Одно-однозначные связи имеют место, когда каждому экземпляру первого объекта (А) соответствует только один экземпляр второго объекта (В) и наоборот, каждому экземпляру второго объекта (В) соответствует только один экземпляр первого объекта (А). Следует заметить, что такие объекты легко могут быть объединены в один, структура которого образуется объединением реквизитов обоих исходных объектов, а ключевым реквизитом может быть выбран любой из альтернативных ключей, т. е. ключей исходных объектов. Графическое изображение одно-однозначной связи приведено на рис. 6. Примером одно-однозначных связей являются группа-староста, фирма — расчетный счет в банке и т. п.

Одно-многозначные связи (1:М) — это такие связи, когда каждому экземпляру одного объекта (А) может соответствовать несколько экземпляров другого объекта (В), а каждому экземпляру второго объекта (В) может, соответство­вать только один экземпляр первого объекта (А). Графическое изображение одно-многозначной связи приведено на рисунке 7.

В такой связи объект А является главным объектом, а объект В — подчиненным, т. е. имеет место иерархическая подчиненность объекта В объекту А. Примером одно-многозначных связей являются подразделения-сотрудники, кафедра-преподаватель, группа-студенты, и т. п.

Много-многозначные связи (М:М) — Это такие связи, когда каждому экземпляру одного объекта (А) могут соответствовать несколько экземпляров второго объекта (В) и наоборот, каждому экземпляру второго объекта (В) может соответствовать тоже несколько экземпляров первого объекта (А), Графиче­ское изображение связи типа M:N показано на рис. 8.

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

Объект-связка должен иметь идентификатор, образованный из идентификаторов исходных объектов: К_А и К_В.

Примером много-многозначных связей является связь поставщики-товары, если один поставщик поставляет разные наименования товаров, а товар одного наименования, доставляется несколькими поставщиками.

Требования нормализации.

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

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

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

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

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

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

53. СУБД Microsoft Access. Свойства полей базы данных.

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

2) Очевидным уникальным свойством любого поля является его Имя. Разумеется, одна база данных не может иметь двух полей с одинаковым именем, поскольку компьютер запутается в их содержимом.

5) Является ли поле ключевым;

6) Обязательное ли поле для заполнения;

7) Уникальное ли поле;

8) Условие на значение: позволяет ввести проверку на вводимые данные;

9) Сообщение об ошибке.

54. СУБД Microsoft Access Основные объекты (таблицы, запросы, формы, отчеты), их назначение и способы создания. Типы данных.

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

Запросы используются для выборки из базы данных информации, необходимой для пользователя. Под выборкой будем понимать динамическую таблицу с записями данных, которые удовлетворяют соответствующим условиям. Запросы обеспечивают быстрый и эффективный доступ к данным, хранящимся в таблице. Благодаря запросам можно не только выполнить сортировку или вычислить выражение, но и свести данные из связанных таблиц. Запросы не хранятся базой данных, информация храниться лишь в таблицах. Но полученная в результате запроса таблица может использоваться в качестве источника данных в формах отчётах и других запросах. Можно ввести поправки в запрос, которые отобразятся в соответствующей таблице.
В таблице данные всегда отсортированы по первичному ключу. Чтобы выполнить сортировку по иным критериям, используются запросы.
Как правило, при составлении таблиц нужно стараться не нагромождать их данными. Создание вычисляемого поля осуществляется путём простого ввода выражений для вычисления в пустом столбце бланка запроса. В квадратные скобки заключаются только имена полей. В результате запроса, в таблице присутствует поле, в котором находится результат вычисления.
Запросы можно разделить на несколько типов: по результатам их действий, особенностям их выполнения, по способу формирования. Чаще всего используются стандартные запросы выбора, используемые для того, чтобы отобрать и представить в виде таблицы интересующие пользователя данные. Нарду со стандартными запросами выбора, можно выделить запросы на выполнение действий, которые используются для создания новых таблиц базы данных.
Наиболее часто встречающимися запросами являются запросы с итогами, с параметром и на вычисление. Запрос с параметром представляет собой запрос на выборку, который отображает диалоговое окно, предназначенное для ввода параметров запроса. Для создания такого запроса в строке Условие отбора в квадратных скобках указывается необходимый параметр. Запрос с итогами – это запрос на выборку, который предназначен не для отображения содержимого записей, а для выполнения итоговых вычислений над хранящимися в них данными.

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

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

Тип данных поля вводится в поле ввода столбцаТип данных.В MS Access допустимыми являются данные следующих типов:

8. Поле объекта OLE;

Каждый из типов данных наделен собственными свойствами, которые отображаются в разделе “Свойства поля” окна конструктора.

Текстовые поля могут содержать буквы, цифры и специальные символы. Максимальная ширина поля составляет 255 символов.

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

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

Поля дат/время Использование для хранения дат и времени полей, в которых данные представлены в специальном формате, предоставляет Вам ряд дополнительных преимуществ:

1. MS Access позволяет вводить и отображать даты в нескольких форматах. Конкретный вариант отображения даты/времени устанавливается в свойстве Формат поля окна конструктора таблиц. При хранении данных эти форматы автоматически преобразуются во внутреннее представление данных.

2. При вводе дат MS Access осуществляет проверку формата данных и допускает ввод только правильных дат.

Данные этого типа занимают 8 байт.

Логические поля используются для хранения данных, которые могут принимать одно из двух возможных значений. Свойство Формат поля логического поля позволяет использовать специальные форматы или один из трех встроенных: Истина/Ложь,Да/НетилиВкл/Выкл. При этом значения Истина, Да и Вкл эквивалентны логическому значению True, а значения Ложь, Нет и Выкл эквивалентны логическому значению False.

Если Вы выберете встроенный формат, а затем будете вводить эквивалентное логическое значение, то введенное значение будет отображаться в выбранном формате. Например, если значениеTrue илиВкл вводится в элемент управления типаПоле, для которого в свойствеФормат поля указано Да/Нет, то введенное значение тут же преобразуется в Да.

При создании специального формата удалите текущее значение из свойства Формати введите свой собственный формат.

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

Поля объекта OLE позволяет хранить в таблицах изображения и другие двоичные данные (например, электронную таблицу MS Excel, документ MS Word, рисунок звукозапись). Фактический объем данных, который Вы можете ввести в поле данного типа, определяется объемом жесткого диска Вашего компьютера (до 1 Гигабайта).

Источник