Размещено на http://www.allbest.ru/

Семантическое кодирование информации

Термин "семантическое кодирование" возник в 60-х годах прошлого века в разработках, посвященных созданию баз данных, различных форм представления знаний, компьютерных методов обработки текстов, а также машинного перевода. Согласно А.М. Кондратову, семантический код - это особый "язык смысла", в котором "из одних понятий - основных - должны выводиться другие". Идея такого языка восходит к Г. Лейбницу, к его "универсальной характеристике", т.е. к знаковой системе, с помощью которой возможно исчисление смыслов. По мнению Г. Лейбница, "все человеческие мысли вполне разрешаются на немногие, как бы первичные". Если этим первичным понятиям будут "поставлены в соответствие характеры, то из них могли бы образовываться характеры производных понятий".

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

Код - это символ, посредством которого объекты предметной области могут быть представлены с целью хранения в памяти ЭВМ и вывода информации на любой носитель.

В области машинной обработки информации различают два типа кодов: машинные и экономические.

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

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

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

Кодовое обозначение характеризуется:

· алфавитом кода;

· структурой кода;

· числом знаков - длиной кода;

· методом кодирования.

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

Структура кода представляет собой, как правило, графическое изображение последовательности расположения знаков кода и соответствующие этим знакам наименования уровней деления. Обычно структура кода представляется в нормативном документе как "ХХ.ХХ".

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

Части кода разделяются между собой точкой, после последней цифры кода точка не ставится. Обозначение года в коде ставится в конце, отделяется дефисом и имеет емкость 4 знака, т.е. "ХХ.ХХ-20ХХ".

Методы кодирования в значительной степени связаны с методами разделения множества на подмножества. При разработке структуры кода важно выбрать оптимальное соотношение между уровнями деления и числом знаков в каждом разряде кода. При этом коды должны удовлетворять следующим основным требованиям:

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

иметь минимальное число знаков (минимальную длину) и достаточное для кодирования всех объектов (признаков) заданного множества;

иметь достаточный резерв для кодирования вновь возникающих объектов кодируемого множества;

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

Выделяют две группы методов, используемых в системе кодирования, которые образуют:

· классификационную систему кодирования, ориентированную на проведение предварительной классификации объектов либо на основе иерархической системы, либо на основе фасетной системы;

· регистрационную систему кодирования, не требующую предварительной классификации объектов. Рассмотрим представленную на рис. 1 систему кодирования.

рис.1

Классификационное кодирование применяется после проведения классификации объектов. Различают последовательное и параллельное кодирование.

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

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

Пример 1. Проведем кодирование информации, классифицированной с помощью иерархической схемы. Количество кодовых группировок будет определяться глубиной классификации и равно 4, Прежде чем начать кодирование, необходимо определиться с алфавитом, т.е. какие будут использоваться символы. Для большей наглядности выберем десятичную систему счисления - 10 арабских цифр. Анализ схемы на рис. 2.4 показывает, что длина кода определяется 4 десятичными разрядами, а кодирование группировки на каждом уровне можно делать путем последовательной нумерации слева направо. В общем виде код можно записать как ХХХХ, где Х - значение десятичного разряда. Рассмотрим структуру кода, начиная со старшего разряда:

1-й (старший) разряд выделен для классификационного признака "название факультета" и имеет следующие значения: 1 - коммерческий; 2 - информационные системы; 3 - для следующего названия факультета и т.д.;

2-й разряд выделен для классификационного признака "возраст" и имеет следующие значения: 1 - до 20 лет; 2 - от 20 до 30 лет; 3 - свыше 30 лет;

3-й разряд выделен для классификационного признака "пол" и имеет следующие значения: 1 - мужчины; 2 - женщины;

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

Принятая система кодирования позволяет легко расшифровать любой код группировки, например:

1310 - студенты коммерческого факультета, свыше 30 лет мужчины;

2221 - студенты факультета информационных систем, от 20 до 30 лет, женщины имеющие детей. Пример 2. Проведем кодирование информации, классифицированной с помощью фасетной схемы. Количество кодовых группировок определяется количеством фасетов и равно 4. Выберем десятичную систему счисления в качестве алфавита кодировки, что позволит для значений фасетов выделить один разряд и иметь длину кода, равную 4. В отличие от последовательного кодирования для иерархической системы классификации в данном метоле не имеет значения порядок кодировки фасетов. В общем виде код можно записать как ХХХХ, где Х - значение десятичного разряда. Рассмотрим структуру кода, начиная со старшего разряда:

1-й (старший) разряд выделен для фасета "пол" и имеет следующие значения: 1 - мужчины; 2 - женщины;

2-й разряд выделен для фасета "наличие детей у женщин" и имеет следующие значения: 1 - есть дети; 2 - нет детей; 0 - для мужчин, так как подобной информации не требуется;

3-й разряд выделен для фасета "возраст" и имеет следующие значения: 1 - до 20 лет; 2 - от 20 до 30 лет; 3 - свыше 30 лет;

4-й разряд выделен для фасета "название факультета" и имеет следующие значения 1 - радиотехнический, 2 - машиностроительный, 3 - коммерческий; 4 - информационные системы; 5 - математический и т.д.

Принятая система кодирования позволяет легко расшифровать любой пол группировки, например:

2135 -женщины в возрасте свыше 30 лет, имеющие детей и являющиеся студентами математического факультета;

1021 - мужчины возраста от 20 до 30 лет, являющиеся студентами радиотехнического факультета.

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

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

Регистрационное кодирование

Регистрационное кодирование используется для однозначной идентификации объектов и не требует предварительной классификации объектов. Различают порядковую и серийно-порядковую систему.

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

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

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

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

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

По сфере действия выделяют следующие виды классификаторов: международные, общегосударственные (общесистемные), отраслевые и локальные классификаторы.

Международные классификаторы входят в состав Системы международных экономических стандартов (СМЭС) и обязательны для передачи информации между организациями разных стран мирового сообщества.

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

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

Локальные классификаторы используют в пределах отдельных предприятий.

Общая технология формирования баз данных как компонента внутримашинной информационной базы автоматизированных библиотечно-информационных систем

Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).

Основная особенность СУБД - это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД). код символ множество

Язык запросов СУБД позволяет обращаться за данными, как из программ, так и с терминалов.

Рис. 1. Связь программ и данных при использовании СУБД

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

Архитектура СУБД

СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:

· физическом размещении в памяти данных и их описаний;

· механизмах поиска запрашиваемых данных;

· проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

· способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

· поддержании баз данных в актуальном состоянии и множестве других функций СУБД.

При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания?

Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) - администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.

Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных.

Рис. 2 Уровни моделей данных

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

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

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

Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.

Модели данных

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

Инфологическая модель должна быть отображена в компьютеро-ориентированную даталогическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели.

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

Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" - поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база - это самый верный способ потерять данные".

Инфологическая модель данных "Сущность-связь"

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

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

Атрибут - поименованная характеристика сущности.

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

Связь - ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

Ограничения целостности

Целостность (от англ. integrity - нетронутость, неприкосновенность, сохранность, целостность) - понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору.

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

Выделяют три группы правил целостности:

1. Целостность по сущностям.

2. Целостность по ссылкам.

3. Целостность, определяемая пользователем.

Мотивировка двух правил целостности, общих для любых реляционных баз данных.

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

2. Значение внешнего ключа должно либо:

3. быть равным значению первичного ключа цели;

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

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

О построении инфологической модели

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

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

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

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

четко разграничивать такие понятия как запрос на данные и ведение данных (ввод, изменение и удаление);

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

плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений.

Реляционная база данных

Реляционная база данных - это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц.

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

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

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

4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных.

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

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

Манипулирование реляционными данными

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

Предложив реляционную модель данных, Э.Ф. Кодд создал и инструмент для удобной работы с отношениями - реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицысклеивать" таблицы (рис. 3).

Некоторые операции реляционной алгебры

Созданы языки манипулирования данными, позволяющие реализовать все операции реляционной алгебры и практически любые их сочетания. Среди них наиболее распространены SQL (Structured Query Language - структуризованный язык запросов) и QBE (Quere-By-Example - запросы по образцу). Оба относятся к языкам очень высокого уровня, с помощью которых пользователь указывает, какие данные необходимо получить, не уточняя процедуру их получения.

С помощью единственного запроса на любом из этих языков можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция).

Процедура проектирования

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

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

2. Представить каждую ассоциацию (связь вида "многие-ко-многим" или "многие-ко-многим-ко-многим" и т.д. между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей.

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

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

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

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

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

8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.



Синтаксис описания проектных решений

Построение инфологической модели

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

1. Создатели (Код создателя, Создатель). Эта сущность отводится для хранения сведений об основных людях, принимавших участие в подготовке рукописи издания (авторах, составителях, титульных редакторах, переводчиках и художниках). Такое объединение допустимо, так как данные о разных создателях выбираются из одного домена (фамилия и имена) и исключает дублирование данных (один и тот же человек может играть разные роли в подготовке разных изданий). Например, С.Я. Маршак писал стихи (Сказка о глупом мышонке) и пьесы (Двенадцать месяцев), переводил Дж. Байрона, Р. Бернса, Г. Гейне и составлял сборники стихов.

2. Так как фамилия и имена (инициалы) создателя могут быть достаточно громоздкими (М.Е. Салтыков-Щедрин, Франсуа Рене де Шатобриан, Остен Жуль Жан-Батист Ипполит и т.п.) и будут многократно встречаться в разных изданиях, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут "Код_создателя", который будет автоматически наращиваться на единицу при вводе в базу данных нового автора, переводчика или другого создателя. Аналогично создаются: Код_издательства, Код_заглавия, Вид_ издания, Код_характера, Код_языка, Номер_билета, Номер_переплета, Код_места и Код_издания, замещающие от одного до девяти атрибутов.

3. Издательства (Код_издательства, Название, Город).

4. Заглавия (Код_заглавия, Заглавие). Выделение этой сущности позволит сократить объем данных и снизить вероятность возникновения противоречивости (исключается необходимость ввода длинных текстовых названий для различных томов собраний сочинений, повторных изданий, учебников и т.п.).

5. Вид_издания (Вид_издания, Название_вида).

6. Характеры (Код_характера, Характер_переиздания).

7. Языки (Код_языка, Язык, Сокращение). Кроме названия языка хранится его общепринятое сокращение (англ., исп., нем., фр.), если оно существует.

8. Места (Код_места, Номер_комнаты, Номер_стеллажа, Номер_ полки).

9. Один из кодов этой сущности (например, "-1") отведен для описания обобщенного места, находящегося за стенами хранилища книг (издание выдано читателю, временно передано другой библиотеке или организации).

10. Читатели (Номер_билета, Фамилия, Имя, Отчество, Адрес, Телефон).

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

1. Издание (Код_издания, Код_заглавия, Вид_издания, Номер_тома, Авторский_знак, Библиотечн_шифр, Повторность, Код_издательства, Год_издания, Аннотация) [Заглавия, Вид_издания, Издательства];

2. Переплеты (Номер_переплета, Код_издания, Цена, Дата_приобретения)[Издания];

Стержневые сущности и обозначения связаны между собой ассоциациями:

1. Авторы [Создатели M, Издание N] (Код_создателя, Код_издания).

2. Составители [Создатели M, Издания N] (Код_создателя, Код_издания).

3. Редакторы [Создатели M, Издания N] (Код_создателя, Код_издания).

4. Художники [Создатели M, Издания N] (Код_создателя, Код_издания).

5. Переводчики [Создатели M, Издания N] (Код_создателя, Код_издания, Язык).

6. Переиздания [Характеры M, Издания N] (Код_характера, Код_издания).

7. Размещение [Места M, Переплеты N] (Код_места, Номер_переплета, Дата_размещения, Дата_изъятия).

8. Выдача [Читатели M, Переплеты N] (Номер_билета, Номер_переплета, Дата_выдачи, Срок, Дата_возврата).



Инфологическая модель базы данных "Библиотека", построенная с помощью языка "Таблицы-связи"

Структурирование информации в базах данных

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

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

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

Требования к базам данных

Итак, хорошо спроектированная база данных:

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

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

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

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

Следующие пункты представляют основные шаги проектирования базы данных:

1. Определить информационные потребности базы данных.

2. Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики (атрибуты) этих сущностей (например, для сущности "деталь" характеристиками могут быть "название", "цвет", "вес" и т.п.) и сформировать их список.

3. Поставить в соответствие сущностям и характеристикам - таблицы и столбцы (поля) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д.).

4. Определить атрибуты, которые уникальным образом идентифицируют каждый объект.

5. Выработать правила, которые будут устанавливать и поддерживать целостность данных.

6. Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.

7. Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.

Основные понятия, используемые в реляционных БД

В реляционной теории одним из главных является понятие отношения. Математически отношение определяется следующим образом. Пусть даны n множеств D1,D2,...,Dn. Тогда R есть отношение над этими множествами, если R есть множество упорядоченных наборов вида, где d1 - элемент из D1, d2 - элемент из D2, ..., dn - элемент из Dn. При этом наборы вида называются кортежами, а множества D1,D2,...,Dn - доменами. Каждый кортеж состоит из элементов, выбираемых из своих доменов. Эти элементы называются атрибутами, а их значения - значениями атрибутов рис. a представляет нам графическое изображение отношения с разных точек зрения.



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

· отношение, таблица, файл (для локальных баз данных);

· кортеж, строка, запись;

· атрибут, столбец, поле.

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

Атрибут (или набор атрибутов), который может быть использован для однозначной идентификации конкретного кортежа (строки, записи), называется первичным ключом. Первичный ключ не должен иметь дополнительных атрибутов. Это значит, что если из первичного ключа исключить произвольный атрибут, оставшихся атрибутов будет недостаточно для однозначной идентификации отдельных кортежей. Для ускорения доступа по первичному ключу во всех системах управления базами данных (СУБД) имеется механизм, называемый индексированием. Грубо говоря, индекс представляет собой инвертированный древовидный список, указывающий на истинное местоположение записи для каждого первичного ключа. Естественно, в разных СУБД индексы реализованы по-разному (в локальных СУБД - как правило, в виде отдельных файлов), однако, принципы их организации одинаковы.

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

Для поддержания ссылочной целостности данных во многих СУБД имеется механизм так называемых внешних ключей. Смысл этого механизма состоит в том, что некоему атрибуту (или группе атрибутов) одного отношения назначается ссылка на первичный ключ другого отношения; тем самым закрепляются связи подчиненности между этими отношениями. При этом отношение, на первичный ключ которого ссылается внешний ключ другого отношения, называется master-отношением, или главным отношением; а отношение, от которого исходит ссылка, называется detail-отношением, или подчиненным отношением. После назначения такой ссылки СУБД имеет возможность автоматически отслеживать вопросы "ненарушения" связей между отношениями, а именно:

· если Вы попытаетесь вставить в подчиненную таблицу запись, для внешнего ключа которой не существует соответствия в главной таблице (например, там нет еще записи с таким первичным ключом), СУБД сгенерирует ошибку;

· если Вы попытаетесь удалить из главной таблицы запись, на первичный ключ которой имеется хотя бы одна ссылка из подчиненной таблицы, СУБД также сгенерирует ошибку;

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

Замечание. Существует два подхода к удалению и изменению записей из главной таблицы:

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

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

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

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

Операции реляционной алгебры

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

2. Объединение R=R1И R2;

3. Пересечение R=R1З R2

4. Вычитание R=R1-R2;

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

6. Декартово произведение R = R1*R2.

7. В результате получается отношение R, содержащее все попарные комбинации строк двух перемножаемых отношений R1 и R2. При этом если отношение R1 обладает арностью k1 и количеством строк s1, а отношение R2 - арностью k2 и количеством строк s2, то результирующее отношение R имеет арность k=k1+k2 и содержит в себе s=s1*s2 строк.

8. Проецирование на атрибуты R = ПРA1,…,An R1.

9. Здесь A1,…,An - атрибуты на которые происходит проецирование. В результате этой операции получается отношение, содержащее только указанные атрибуты исходного отношения. Количество строк в отношении при этом остается прежним.

10. Операция выборки R = ПРУСЛОВИЕ R1.

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

12. Операция соединения отношений по определенному условию.

Почему БД может быть плохой?

Приведем пример плохой БД. Пусть проектируется база "Питание". Эту базу можно представить в виде одного отношения, представленного на рисунке.

Начинающий проектировщик будет использовать данное отношение в качестве завершенной БД. Действительно, зачем разбивать его на несколько более мелких отношений, если оно заключает в себе все данные? А разбивать надо потому, что при использовании такого единственного отношения возникает несколько проблем:

1. Избыточность. Данные практически всех столбцов многократно повторяются. Повторяются и некоторые наборы данных (Блюдо-Вид-Рецепт, Продукт-Калорийность, Поставщик-Город-Страна). Нежелательно повторение рецептов, некоторые из которых намного больше рецепта "Лобио". И уж совсем плохо, что все данные о блюде (включая рецепт) повторяются каждый раз, когда это блюдо включается в меню.

2. Потенциальная противоречивость (аномалии обновления). Вследствие избыточности можно обновить адрес поставщика в одной строке, оставляя его неизменным в других. Если поставщик кофе сообщил о своем переезде в Харбин и была обновлена строка с продуктом кофе, то у поставщика "Хуанхэ" появляется два адреса, один из которых не актуален. Следовательно, при обновлениях необходимо просматривать всю таблицу для нахождения и изменения всех подходящих строк.

3. Аномалии включения. В БД не может быть записан новый поставщик ("Няринга", Вильнюс, Литва), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно, конечно, поместить неопределенные значения в столбцы Блюдо, Вид, Порций и Вес (г) для этого поставщика. Но если появится блюдо, в котором используется этот продукт, не забудем ли мы удалить строку с неопределенными значениями?



По аналогичным причинам нельзя ввести и новый продукт (например, Баклажаны), который предлагает существующий поставщик (например, "Полесье"). А как ввести новое блюдо, если в нем используется новый продукт (Крабы)?

4. Аномалии удаления. Обратная проблема возникает при необходимости удаления всех продуктов, поставляемых данным поставщиком или всех блюд, использующих эти продукты. При таких удалениях будут утрачены сведения о таком поставщике.

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

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

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

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

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

Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (5НФ). С практической точки зрения, достаточно трех первых форм - следует учитывать время, необходимое системе для "соединения" таблиц при отображении их на экране. Поэтому мы ограничимся изучением процесса приведения отношений к первым трем формам.

Этот процесс включает:

· устранение повторяющихся групп (приведение к 1НФ);

· удаление частично зависимых атрибутов (приведение к 2НФ);

· удаление транзитивно зависимых атрибутов (приведение к 3НФ).

Приведение к первой нормальной форме

Когда поле в данной записи содержит более одного значения для каждого вхождения первичного ключа, такие группы данных называются повторяющимися группами. 1НФ не допускает наличия таких многозначных полей. Иными словами, значение каждого атрибута должно быть атомарным. Полная формулировка 1-й НФ следующая:

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

Приведение ко второй нормальной форме

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

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

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

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

Приведение к третьей нормальной форме

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

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

Литература

1. Воройский Ф.С. Информатика: Новый систематизированный толковый словарь-справочник (Вводный курс по информатике и вычислительной технике в терминах). - М.: Либерея, 2001. - 536 с.

2. Стандарты по библиотечно-информационной деятельности. - СПб.: Профессия, 2003, С. 11-38.

3. Информатика: Учебник / Под ред. проф. Н.В. Макаровой. - М.: Финансы и статистика, 2004. - 768 с.

4. Федеральный Закон "Об информации, информатизации и защите информации" // НТИ. Сер. 1. - 1995. - № 2. - С. 2-8.

5. UNIMARC: Вводный курс / Под ред. Я.Л. Шрайберга. - М., 1995. - 28 с.

Дополнительная литература

1. Воройский Ф.С. Информатика: Новый систематизированный толковый словарь-справочник (Вводный курс по информатике и вычислительной технике в терминах). - М.: Либерея, 2001. - 536 с.

...