uzluga.ru
добавить свой файл
1
Основные типы данных

Текстовые данные. Значение каждого текстового (символьного) данного представлено совокупностью произвольных алфавитно-цифровых символов, длина которой чаще всего не превышает 255 (например, 5, 10, 140). Текстовыми данными представляют в ИС фамилии и должности людей, названия фирм, продуктов, приборов и т.д. В частном случае значение текстового данного может быть именем какого-то файла, который содержит неструктурированную информацию произвольной длины (например, биографию или фотографию объекта). Фактически это структурированная ссылка, позволяющая резко расширить информативность вашей таблицы.

Например, в некоторых системах по соглашению можно добавить к телефонному справочнику текстовое поле небольшой длины и записывать в это поле имена графических файлов с фотографиями (скажем, foto001.pcx, foto002.pcx и т.д.). Просматривая справочник на дисплее и нажимая определенную клавишу, вы будете получать на экране фотографию объекта. Разумеется, если при записи данных в таблицу вы перепутаете имена файлов, вместо дяди Пети на экране может появиться тете Маша, а то и что-нибудь похуже. (Заметим, что современные алгоритмы не позволяют отличить не только тетю Машу от дяди Пети, но и кошку от собаки).

Числовое данное. Данные этого типа обычно используются для представления атрибутов, со значениями которых нужно проводить арифметические операции (весов, цен, коэффициентов и т.п.). Числовое данное, как правило, имеет дополнительные характеристики, например: целое число длиной 2 байта, число с плавающей точкой (4 байта) в фиксированном формате и др. Разделителем целой и дробной частей в современных системах обычно служит запятая (но иногда употребляется и точка).

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

Данное типа даты и (или) времени. Данное типа даты задается в каком-то известном машине формате, например, ДД.ММ.ГГ (день, месяц, год). С первого взгляда – это частный случай текстового данного. Однако использование в ИС особого типа для даты имеет следующие преимущества. Во-первых, система получает возможность вести жесткий контроль (например, значение месяца может быть только дискретным в диапазоне 01-12). Во-вторых, появляется возможность автоматизированного представления формата даты в зависимости от традиций той или иной страны (например, в США принят форма ММ-ДД-ГГ). В-третьих, при программировании резко упрощаются арифметические операции с датами (попробуйте, например, вручную вычислить дату спустя 87 дней после заданного числа). Те же преимущества имеет использование данного типа времени.

Логические данные. Данное этого типа (иногда его называют булевым) может принимать только одно из двух взаимоисключающих значений – TRUE или FALSE (условно: 1 или 0). Его значение можно интерпретировать как «Да» и «Нет» или как «Истина» и «Ложь». Логический тип удобно использовать для тех атрибутов, которые могут принимать одно из двух взаимоисключающих значений, например: наличие водительских прав (да - нет), исправность ручного тормоза (да – нет) и т.п.

Поле объекта OLE. Вероятно, это самый интересный тип. «Значением» такого данного может быть любой объект OLE, который имеется на вашем компьютере (графика, звук, видео). В частности, в свой телефонный справочник вы можете включить не только статистическую фотографию дяди Пети, но и его голос, улыбку и походку.

Гиперссылка. Если после объявлено гиперссылкой, то двойным щелчком по нему вы можете мгновенно прейти к любому документу Windows (в том числе к странице Интернет).

Пользовательские типы. Во многих системах пользователям предоставляется возможность создавать собственные типы данных, например: «День недели» (понедельник, вторник и т.д.), «Адрес» (почтовый индекс – город - …) и др.

! В частном случае значение текстового данного может быть совокупность пробелов, а значение числового данного – нулем. Если же в таблицу вообще не введена информация, значение будет пустым (NULL). Не следует путать NULL (отсутствие данных) и нулем или пробелами. Во многих системах пользователю важно зафиксировать отсутствие данных для каких-то экземпляров объекта (например, при отсутствии адреса значение поля «адрес» равного NULL). Если случайно ввести в такую строку таблицы пробел, система сочтет, что адрес задан, и данный экземпляр не попадет в список экземпляров объектов с отсутствующими адресами.

Что такое реляционный подход


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

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

Теория реляционных БД – это сложная математическая дисциплина, основы которой разработал в 70-х годах доктор Э.Кодд (США). Основная терминология баз данных зависит от уровня описания (теория или практика), конкретного класса системы (Dbase, Access, «клиент-сервер») и от категории читателей. Мы свели терминологию в следующую таблицу.

Теория БД

Реляционные БД

Наши соглашения

Отношение

(Relation)

Таблица (Table)

Таблица

Картеж (Tuple)

Строка (Row)

Строка

Атрибут (Attribute)

Столбец (Column)

Поле (Field)


Примечание. В теории БД совместно с термином «Атрибут» (а иногда и вместо него) часто употребляют сочетание «Домен (domain) атрибута». Домен – это множество допустимых значений данного атрибута (например, множество категорий в таблице SLOVKAT, множество стран в таблице стран).

Перечислим основные понятия реляционных БД, которые будут использоваться далее.

  1. В реляционных БД любые совокупности данных представляются в виде двухмерных таблиц, подобных описанным выше телефонному справочнику и справочнику цен.

  2. Каждая таблица состоит из фиксированного числа столбцов (TELEFON – из четырех, SLOVKAT – из двух) и некоторого (переменного) количества строк. Описание столбцов, составляемое разработчиком, принято называть макетом таблицы.

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

  • уникальное имя поля;

  • тип поля (тип данных);

  • дополнительные характеристики (длину, формат).

  1. Каждая строка таблицы на языке компьютера называется записью (record). Система нумерует записи по порядку: 1, 2, …, n, где n – общее число записей (строк) в таблице на данный момент. В отличие от количества полей (столбцов) в таблице, количество записей в процессе эксплуатации БД может как угодно меняться (от нуля до миллионов). Количество полей, их имена и типы тоже можно изменить, но это уже особая операция, которая называется изменением макета таблицы (или реорганизацией таблицы).

  2. Каждое поле может входить в несколько таблиц (например, поле КАТЕГ входит в обе эти таблицы).

Далее мы будем рассматривать реляционный подход и принципы создания ИС в MS Access на двух простых примерах. Пример 1 – это телефонный справочник, а пример 2 – простейшая система учета продаж торговой фирмы, описанная ниже.

Пусть некая фирма занимается торговлей кондитерскими изделиями (конфетами, печеньем, пастилой и т.д.). Клиентами (покупателями) фирмы являются рестораны, кафе, клубы и т.п. Для учета и анализа заказов фирма может вести таблицу с именем ЗАКАЗЫ и со следующими полями:





Имя поля

Примечание

Тип поля

1

Номер заказа

-

Число

2

Код клиента

-

Число

3

Наименование клиента

-

Текст

4

Адрес клиента

-

Текст

5

Код клиента

-

Число

6

Название продукта

-

Текст

7

Количество

кг

Число

8

Дата поставки

ДД.ММ.ГГГГ

Дата

9

Цена

руб./кг

Число

10

Стоимость

руб.

Число


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


Символы масок ввода



Значение

Означает

0

В данную позицию должна быть введена цифра (и ничего кроме цифры)

9

В данную позицию может быть введена цифра или пробел

#

В данную позицию может быть введена цифра, пробел или знаки плюс, минус

L

В данную позицию должна быть введена буква (и ничего кроме буквы)

?

В данную позицию может быть введена буква (и ничего кроме буквы)

A

В данную позицию должна быть введена буква или цифра (и ничего кроме этого)

a

В данную позицию может быть введена буква или цифра (и ничего кроме этого)

&

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

C

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

<

При вводе все символы правее конвертируются к верхнему регистру

>

При вводе все символы правее конвертируются к нижнему регистру

!

Access заполняет маску ввода данными справа налево

\

Следующий символ будет изображен в маске без изменений (так, как введен)

Пароль

Все вводимые символы заменяются*


Общие механизмы реляционного подхода


Нормализация

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

Таблицу ЗАКАЗЫ мы намеренно спроектировали плохо. Это черновой набросок, список данных, который обычно создает разработчик, прежде чем взять за нормализацию.

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

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

Продолжив рассмотрение таблицы ЗАКАЗЫ, мы обнаружим еще три лишних поля:

  • название продукта;

  • цена продукта;

  • стоимость продукта.

Значение первых двух полей не зависят от номера заказа, но зависят от кода продукта. Поэтому и место этих полей – в классификаторе ПРОДУКТЫ (код, название, цена).

Значение поля СТОИМОСТЬ – это произведение цены на количество, поэтому его вообще не следует включать в таблицы: система обязана при необходимости просто вычислить стоимость заказа.

Таким образом, в результате нормализации исходной таблицы ЗАКАЗЫ мы получили три таблицы:

  • одну оперативную таблицу ЗАКАЗЫ (номер заказа, код клиента, код продукта, количество и дата поставки);

  • классификатор КЛИЕНТЫ (код клиента, наименование клиента и адрес клиента);

  • классификатор ПРОДУКТЫ (код продукта, название продукта, цена).

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

Помните, что каждая таблица – это всегда класс объектов (в нашем случае – заказов, клиентов и продуктов). В системе «Заказы» первая таблица является оперативной, а остальные – справочными. Оперативная таблица меняется часто (это перечень текущих заказов), а справочники – редко, из легко выправить раз и навсегда, внося в дальнейшем лишь небольшие изменения.

Необходимо иметь в виду, что это различие – чисто условное. Изменив постановку задачи, мы можем заняться не столько заказами, сколько клиентами или продуктами. Например, службу маркетинга могут интересовать не только наименование и адрес клиента, но и фамилия (Ф.И.О.) директора (напомним, что клиент – это ресторан, кафе, клуб), а также его возраст, характер, склонности… Включив эти данные в таблицу КЛИЕНТЫ, добавив туда потенциальных клиентов, служба маркетинга сможет решать собственные задачи.

При проектировании таких таблиц, как ЗАКАЗЫ, рекомендуем «золотые правила»:

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

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

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

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

! Если при просмотре подготовленной БД вы обнаружили в паре таблиц одноименное поле, которое не входит в первичный ключ ни одной из этих таблиц, - это ошибка нормализации. Система не сможет контролировать согласованность значений таких полей.


Кодирование информации

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

Во-первых, резко увеличивается объем вводимой информации (особенно если поле входит не в одну, а в несколько таблиц): ведь названия люди набирают по-разному (например, «Тульский завод», «Тульский з-д» и т.д.), и машина запутается в этом творчестве.

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

Разумеется, можно допустить ошибку и при вводе кода (например, вместо 708 набрать 709), однако это тема особого разговора.

Непременное условие корректности кода – его уникальность. Это означает, что, если вы присвоили, скажем, должности «старший бухгалтер» код 07, этот код не может принадлежать никакой другой должности.

Примечание. В современных ИС коды часто скрыты от пользователя, и при вводе данных значение атрибута (название) просто выбирается из классификатора.


Повторяющиеся группы

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

Например, одной из простейших, реляционных по своей природе структур является система управления персоналом.

Естественно желание разработчика включить в систему исчерпывающую информацию о работнике, объем которой от человека к человеку сильно меняется, а именно: прежняя работа, передвижение по службе, командировки, научные премии, взыскания, заболеваемость, печатные труды, увлечения и др. В принципе можно включить все это в основную таблицу, однако число полей придется брать по максимально возможному. Допустим, ученый может иметь до 30 премий. Тогда потребуется включить в таблицу 60 полей вида: ДАТА1, КОД1, ДАТА2, КОД2, …, где ДАТАN – дата получения премии, а КОДN – код премии. Большая часть значений этих полей в конкретных записях будет «пустой».

Такую информацию, разную по объему для каждого экземпляра объекта, называют повторяющимися группами. Задача решается просто, если для каждой повторяющейся группы завести отдельную таблицу, каждую со своим ключом. Например, можно сождать таблицу ПРЕМИИ с тремя столбцами: Табельный номер (НОМЕР), Дата присуждения (ДАТА), КОД ПРЕМИИ.

Первичным ключом в этой таблице является НОМЕР+ДАТА, если считать, что в один день работник не может получить две премии. Если это не так, ключом будет вся запись (включая код премии).

Одновременно в базу данных введем словарь SLPREM (СЛоварь ПРЕМий) с кодами и названиями премий: 01 – Нобелевская премия, 02 – Гонкуровская премия, 03 - золотая медаль им. М.В.Ломоносова и проч.

В дальнейшем с помощью программных средств мы легко можем объединить основную таблицу и ПРЕМИИ с включением наименований премий из SLPREM.


Достоверность информации

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

Многие данные как в одной таблице, так и в разных таблицах логически связаны между собой. Допустим, в одной из записей таблицы ЗАКАЗЫ на месте кода клиента вы указали сочетание, которое отсутствует в классификаторе КЛИЕНТЫ. Система укажет вам на ошибку.

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

Кроме того, в современных ИС можно указать условия, которым должны удовлетворять значения некоторых полей (условия верификации данных).

Гораздо сложнее обстоит дело с ошибками в допустимых значениях данных. Например, если в той же таблице ЗАКАЗЫ вы указали существующий, но неверный код клиента, компьютер обнаружить эту ошибку не в состоянии.