поле логического типа содержит

Определение полей

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

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

Рекомендуется не использовать очень длинные имена, т. к. они плохо запоминаются, и не включать в имена большое количество пробелов, особенно если с именами предполагается работать с помощью процедур Visual Basic for Application. Чтобы следовать этой рекомендации и при этом получать понятные имена, можно либо использовать вместо пробелов между словами знак подчеркивания (_), либо писать все слова слитно, но каждое начинать с заглавной буквы.

После ввода имени поля необходимо задать тип данных, которые будут находиться в этом поле. Наиболее удобным способом является выбор типа из списка, но наименование типа можно ввести и вручную. Обычно при ручном вводе Конструктор автоматически предлагает закончить вводимое название типа. В Microsoft Access имеются следующие типы данных:

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

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

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

Рассмотрим основные свойства полей для каждого типа данных.

Источник

Поле логического типа содержит

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

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

Рекомендуется не использовать очень длинные имена, т. к. они плохо запоминаются, и не включать в имена большое количество пробелов, особенно если с именами предполагается работать с помощью процедур Visual Basic for Application. Чтобы следовать этой рекомендации и при этом получать понятные имена, можно либо использовать вместо пробелов между словами знак подчеркивания (_), либо писать все слова слитно, но каждое начинать с заглавной буквы.

После ввода имени поля необходимо задать тип данных, которые будут находиться в этом поле. Наиболее удобным способом является выбор типа из списка, но наименование типа можно ввести и вручную. Обычно при ручном вводе Конструктор автоматически предлагает закончить вводимое название типа. В Microsoft Access имеются следующие типы данных:

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

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

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

Рассмотрим основные свойства полей для каждого типа данных.

Источник

Типы данных и полей: общее и в разных СУБД

Характеристики полей БД и типы данных

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

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

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

Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!

Характеристики полей БД (на основе xBase)

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

Характеристики основных полей MySQL

* Размер для символьных (строковых) полей зависит от используемой кодировки.

Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!

Неверный выбор типа и размера полей

Поскольку размер поля в «правильной» реляционной БД имеет фиксированное значение, он должен быть достаточным (иначе данные могут не поместиться) но не избыточным (лишнее место на диске и в памяти). Если подумать, то данный параметр должен быть, например, для символьного типа точно равен самой длинной строке генеральной совокупности.

Тип поля должен соответствовать вводимым данным с учетом возможного развития. В том числе числу записей для идентификаторов.

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

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

Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!

Прошу обратить особо пристальное внимание на неопределенную информацию, традиционно вносимую для xBase в Memo-поле. Новые концепции не предусматривают такого типа и придется пользоваться текстовыми полями, дополнительно обдумывая их структуру. Важно создать среду, когда не будет вывода пользователю, что он превысил объем сохраняемых данных.

Источник

Логические поля в базах данных, есть ли противоядие

Часто в таблицах содержится большое количество логических полей, проиндексировать все из них нет возможности, да и эффективность такой индексации низка. Тем не менее, для работы с произвольными логическими выражениями в SQL пригоден механизм многомерной индексации о чем и пойдёт речь под катом.

В SQL логические поля используются в основном в двух случаях. Во-первых, когда действительно нужен бинарный атрибут, например, ‘купля/продажа’ в таблице сделок. Такие атрибуты редко меняются со временем.

Во-вторых, для записи состояния конечного автомата, которым описывается запись. Имеется в виду, что логический объект, соответствующий записи таблицы, проходит ряд состояний, число которых и переходы между которыми определяются прикладной логикой. Простой пример — техника “soft-delete”, когда запись физически не уничтожается, а только помечается как удалённая.

Если автомат сложный, таких полей может быть изрядное количество, в одной из наших таблиц 58 (+14 устаревших) таких полей (включая наборы флагов) и это не что-то из ряда вон выходящее. Так не было задумано изначально, но по мере развития продукта и изменения внешних требований развиваются и соответствующие автоматы, приходят и уходят разработчики, меняются аналитики… в какой-то момент может оказаться безопаснее завести новый флаг, нежели разбираться во всех хитросплетениях. Тем более что накопились исторические данные и их состояния обязаны оставаться адекватными.

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

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

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

Пусть, в таблице T1 есть два булевых поля: F1 & F2, а запрос

Т.е. хотя, по F1 & F2 выпадение true и false равновероятно, сочетание (true,false) выпадает только один раз из тысячи. В результате, если раздельно проиндексировать F1 & F2 и принудить использовать эти индексы в запросе, SQL-процессору пришлось бы прочитать по половине обоих индексов и пересечь результаты. Возможно, дешевле прочитать всю таблицу и вычислить выражение для каждой строчки.

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

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

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

Дизъюнктивная нормальная форма

Единичный запрос к многомерному индексу представляет собой многомерный прямоугольник, ограничивающий пространство запроса. Если поле участвует в запросе, для него задаётся ограничение. Если нет, прямоугольник по этой координате ограничен только разрядностью данной координаты. Логические координаты имеют разрядность 1.

Поисковый запрос в таком индексе является цепочкой из & (конъюнкцией), например, выражение: v1 & v2 & v3 & (!v4), эквивалентно v1:[1,1], v2:[1,1], v3:[1,1], v4:[0,0]. А все остальные поля имеют диапазон: [0,1].

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

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

Есть и одно НО. Такое преобразование в некоторых случаях может привести к экспоненциальному росту размера выражения. Например, преобразование из

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

Алгоритм многомерной индексации

Для многомерной индексации используются свойства самоподобной нумерующей кривой на основе гипер-кубических симплексов со стороной 2. Как оказалось, практическое значение имеют два варианта таких кривых — Z-кривая и кривая Гильберта.

Фиг.1 двумерная Z-кривая, 3 и 6 итерации

Фиг.2 двумерная кривая Гильберта, 3 и 6 итерации

Фиг.3 Пример поиска в двумерном индексе (Z-кривая)

На фиг.3 показано разбиение исходного поискового экстента на подзапросы и найденные при этом точки. Использовался двумерный индекс, построенный на случайном равномерно распределенном наборе 100 000 000 точек в экстенте [1 000 000, 1 000 000].

Логический многомерный индекс

Раз уж речь зашла о многомерном индексировании, самое время задуматься, а насколько многомерным он может быть? Есть ли какие-то объективные ограничения?

Конечно, ведь B-дерево имеет страничную организацию и для того, чтобы быть деревом, на странице должно гарантированно помещаться не менее двух элементов. Если принять страницу за 8К, значит на хранение одного элемента не может уходить больше 4К. В 4К без сжатия влезает около 1000 32-разрядных значений. Это довольно много, выше пределов любого разумного применения, можно сказать, что физические пределы практически не доступны.

Есть и другая сторона, каждое дополнительное измерение отнюдь не бесплатно, на него уходит дисковое пространство и замедляется работа. С точки зрения “физического смысла”, в один индекс должны попадать поля, которые меняются одновременно и поиск по ним тоже идёт совместно. Никакого смысла индексировать всё подряд нет.

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

Правда, есть нюансы:

Численный эксперимент

Фиг.4 Результаты, число прочитанных страниц в разных сериях

По Y — отложены количества прочитанных страниц.
По X — сдвиг полос от самого младшего (48) разряда к старшему. Полосы разной ширины подписаны и отмечены разными цветами.

Фиг.5 Те же данные что и Фиг.4, другое представление

По X — сдвиг полосы
По Y — ширина полосы

Что следует отметить:

Эксперимент на реальных данных

Таблица Trades, всего 278 479 918 строк, данные одного из тестовых контуров.
Результаты выполнения некоторых запросов в таблице ниже:

На чтение/обработку одной страницы в среднем уходит 0.8 мсек.

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

Но прежде чем данная техника сможет принести практическую пользу, предстоит еще очень много сделать. Так что, продолжение следует.

Источник

Определение полей.

Дата добавления: 2013-12-24 ; просмотров: 2972 ; Нарушение авторских прав

Желательно придерживаться следующих правил:

· имена полей в таблице не должны повторяться;

· имена полей не могут содержать более 64 символов, включая пробелы;

· избегать употребления полей, совпадающих с именами встроенных свойств или функций MS Office;

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

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

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

Access допускает один из девяти типов данных для любого поля, которыми могут быть: Текстовый, Поле МЕМО, Числовой, Дата/Время, Денежный, Логический, Счетчик, Поле объекта OLE, Гиперссылка, Мастер подстановок

Тип данных Текстовый – используется для хранения символьных или числовых данных, не требующих вычислений. Максимальная длина – 255 символов. Система не сохраняет пустые символы в неиспользованной части текстового поля, что уменьшает общий размер базы данных.

Тип данных ПОЛЕ МЕМО используется для хранения длинного текста или комбинации текста и чисел, содержащих более 255 символов (до 65 536 символов).

Тип данных Числовой – используется для хранения числовых данных, используемых в математических расчетах. Имеет много подтипов (размеров): байт, целое (2 байта), длинное целое (4 байта), одинарное с плавающей точкой (4 байта, 7 знаков в дробной части), двойное с плавающей точкой (8 байт, 15 знаков в дробной части) и др.

От выбора размера числового поля зависит точность вычислений. По умолчанию используется Длинное целое, которое занимает 4 байта и представляет число от –2114777483648 до 21477483647.

Тип данных Дата/Времяиспользуется для хранения даты и времени. Позволяет вводить даты с 100 по 9999 год. Размер поля 8 байт. Система предоставляет большой выбор форматов для отображения даты и времени, но хранит их в специальном фиксированном числовом формате.

Тип данных Денежный предназначен для хранения данных, точность представления которых колеблется от 1 до 4 знаков после запятой. Целая часть может содержать до 15 десятичных знаков. Размер этого поля – 8 байт.

Тип данных Счетчик содержит 4 байтный уникальный номер каждой вновь вводимой записи. Поле счетчика может генерировать три типа чисел: последовательно возрастающие на единицу, случайные числа, а также коды репликации (также называемые GUID — глобальные уникальные идентификаторы). Наиболее часто используется счетчик последовательно возрастающих чисел. Такой тип счетчика удобно использовать как первичный ключ таблицы. Счетчик случайных чисел создает случайный номер для каждой записи в таблице. Код репликации используется при репликации базы данных для создания уникальных идентификаторов, обеспечивающих

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

Тип поля Логический – содержит только одно из двух значений, интерпретируемых как ДА/Нет или Истина/Ложь, Включено/Выключено. Поле логического типа не может быть ключевым, но его можно индексировать.

Поле объекта OLE (до 1 Гбайта, ограничивается объемом диска) содержит ссылку на объект любого приложения Windows (формулу, рисунок, лист или книгу Excel и т.д.). В каждой конкретной записи тип данного этого поля определяется типом вставленного в него объекта. Размер поля ограничен свободным дисковым пространством на Вашем ПК.

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

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

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

Свойство Размер поля определяет максимальный размер данных, которые могут сохраняться в полях с типом данных Текстовый, Числовой или Счетчик. Рекомендуется задавать минимально допустимое значение свойства Размер поля, поскольку обработка данных меньшего размера выполняется быстрее и требует меньше памяти.

Размер текстового поля – от 0 до 255.

Свойство Формат поля позволяет указать форматы вывода всех типов данных, кроме OLE, на экран и на печать. Например, для поля «Цена» разумно указать в свойстве Формат поля формат «Денежный» и установить для его свойства Число десятичных знаков значение 2 или «Авто». В этом случае введенное в поле значение 4321,678 будет отображаться как 4 321,68р.

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

Существуют встроенные (стандартные) форматы данных и специальные.

Рассмотрим сначала встроенные форматы.

Ниже перечислены стандартные значения свойства «Формат поля», допустимые для числовых, дата, логических, денежных и полей типа счетчик.

Стандартный числовой: изображает числа так, как они были введены (используется по умолчанию). Например, 3456,789

Денежный: Использует разделитель тысяч; отрицательные числа изображаются заключенными в скобки; свойство «Число десятичных знаков» имеет значение 2. Например: 3 456,79 р.

Фиксированный: Изображает, по крайней мере, один символ; свойство «Число десятичных знаков» имеет значение 2.

С разделителями тысяч: использует разделитель тысяч; свойство «Число десятичных знаков» имеет значение 2. Например: 3 456,79

Процентный: умножает значение на 100; добавляет знак процента; свойство «Число десятичных знаков» имеет значение 2.

Экспоненциальный: использует экспоненциальный формат (например, 1.05х10 ).

Для типа Дата/Время существует следующий набор форматов:

Полный даты: если значение содержит только дату, то время не изображается; если значение содержит только время, то дата не изображается (используется по умолчанию). Примеры: 03.04.93 05:34:00, 03.04.93 и 05:34:00.

Длинный даты: Пример: Суббота, 3 апреля 1993 г.

Средний даты: Пример: 03-апр-93.

Краткий даты: Пример: 03.04.93.

Длинный времени: Пример: 05:34:00.

Средний времени : Пример: 05:34.

Краткий времени: Пример: 17:34.

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

Да/Нет; Истина/Ложь; Вкл/Выкл.

Для любого формата можно указать точное число знаков в дробной части, задав значение свойства «Число десятичных знаков»).

Специальные форматы, создаются при помощи символов форматирования.

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

первый раздел – формат для положительных чисел;

второй раздел– формат для отрицательных чисел;

третий раздел– формат для нулевых значений;

четвертый раздел– формат пустых значений.

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

# прототип разряда (вводится цифра или ничего не вводится)

% процентный формат (число умножается на 100 и добавляется знак %)

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

· * (Звездочка) – приводит к заполнению доступного пространства символом, указанным сразу после звездочки;

· [ЦВЕТ] – прямоугольные скобки указывать обязательно, а в них цвет – Black, Blue, Red и т.д

Источник