Введение в базы данных

1.1.3 Записи, типы данных, наборы записей

Данные хранятся обычно в виде записей. Пример простой записи:

(10, 'ACCOUNTING', 'NEW YORK').

Заметим, что для работы с ней необходимо разобраться с семантикой, то есть с системой смыслов, связанных с этой записью. Это запись чего? Что такое "ACCOUNTING" Может быть название книги об учёте? A "NEW YORK" —это место её издания? А что тогда обозначает число 10? В действительности имелось в виду, что приведенная запись входит в набор записей с именем "ОТДЕЛЫ" (рисунок 1.1). Первое поле записи —номер отдела, второе поле — это название отдела, а третье обозначает город, в котором отдел находится.

Уточним термины:

В примере, приведённом выше, поле "номер отдела" — ключ. Если вам кажется, что ключ можно было выбрать и по-другому, то вы правы.

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

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

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

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

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

сотрудник(1101, Пирогов Олег Николаевич, лаборант, адрес(999000, НьюМосква, Длинная, 140, 5), 4000)

Дерево схемы этой записи изображено на рисунке 1.2.

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

Возможно, приведенная в примере форма записи в настоящее время устраивает пользователей базы. Но может быть следует подумать о том, не придётся ли в дальнейшем изменять схему, например, из-за того, что появятся филиалы в других государствах? А нужно ли фамилию, имя и отчество записывать в одном поле? А как быть с теми, у кого нет отчества? И вообще, как записать Ламарка, которого, как известно, при жизни именовали Жан Батист Пьер Антуан де Моне шевалье де Ламарк?

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

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

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

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

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

Интервальные типы выделены из-за двух своих особенностей. Само название "интервальный" дано потому, что операции вроде разности дают результат, выводящий за рамки базисного типа. Так, разность между двумя датами, например, "30 декабря" и "29 декабря", есть один день. Это не дата, а число. Вторая особенность в том, что некоторые операции над данными интервальных типов смысла не имеют. Что означала бы сумма тех же дат, 30 и 29 декабря?

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

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

Не повезло в базах логическому типу. Очень часто он отсутствует. Поэтому приходится представлять его, например, числовым типом со значениями 1 как TRUE и 0 как FALSE.

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

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

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

Домен должен иметь уникальное в пределах базы данных имя. Определяется он на некотором типе данных или на другом домене. Домен характеризуется условием, выделяющим подмножество данных описываемого домена.

Пример: Домен вычислимого поля "возраст (человека)" характеризуется условием (возраст>0 и возраст<120). На нём с помощью условия возраст<7 можно определить домен "возраст воспитанника детского сада".

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

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

Пример структуры набора записей приведен на рисунке 1.3. Цифра после имени типа, например Текст(20), означает допустимое число символов.

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

1.1.4 Схема базы, данные и метаданные

Вспомним, что схема записи это описание ее структуры.

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

Пример: два набора записей — "сотрудник" и "отдел" со следующими схемами:

Может быть, вам показалось странным объединение слов многословного имени с помощью символа подчёркивания, например "номер_отдела". Это делается для того, чтобы любое имя представлялось последовательностью символов, не разрываемой пробелами. Так удобнее выделять имена. Свяжем эти наборы записей через поля "номер_отдела", имея в виду, что у каждого сотрудника в поле "номер_отдела" должен стоять номер отдела, который имеется в одной из записей набора "отдел" и не может быть номера, не указанного в одной из записей набора "отдел". Остается добавить схему связи:

связь_сотр_отд(сотрудник. номер_отдела, отдел. номер_отдела)

Точечный синтаксис в именах позволяет связать несколько уровней представления данных. Если необходимо указать поле "номер_отдела" из набора "сотрудник", пишем "сотрудник.номер_отдела".

Для практического использования приведенной схемы следовало бы уточнить многие подробности. Например, как-то указать, что в отделе может не быть сотрудников, что один сотрудник не может работать в двух отделах и т.д. Сейчас мы не будем заниматься такими деталями.

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

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

Часть метаданных записана в двух таблицах. Ml содержит перечень таблиц, М2 —перечень столбцов (таблица 1.2, таблица 1.3). Если метаданные имеются, появляется возможность перед выполнением любого действия проверить правильность его записи (синтаксиса). Можно узнать, существуют ли таблицы, к которым обращаются, правильно ли названы столбцы и т.д.

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

1.2 Модели данных. Базы данных и файловые системы.

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

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

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

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

Примеры декларативных ограничений целостности:

В наборе записей со схемой Сотрудник (ИНН, ФИО, Должность, Зарплата, Бонус) для каждой записи должно выполняться условие Бонус < 0.2 * Зарплата

Замечание. Ограничения типа Check строятся на данных одной записи.

Пример процедурного ограничения целостности: В наборе записей из последнего примера предусмотрим возможность изменения поля "Зарплата" только в сторону уменьшения.

Почему это ограничение не декларативно? Потому, что назначаемая зарплата в базе данных пока еще не записана и отношение "Новая_зарплата" < "Старая_зарплата" нельзя выразить через данные, имеющиеся в базе.

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

1.2.2 Неопределенные значения (NULL)

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

Можно в рамках типа данных придумать особые значения для указания на то, что значение отсутствует. В нашем примере можно было бы, скажем, для тех, кому не положены комиссионные, записывать значение — 1 и, анализируя его, отбрасывать строки, содержащие —1, при подсчёте средних комиссионных. Но такой подход не универсален. Если поле допускает отрицательные значения, придется придумать какое-то другое выделенное значение.

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

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

Помните, что пустое значение (число 0 или пустая строка), часто задаваемое по умолчанию — это не NULL.

Любые алгебраические операции (сложение, умножение, конкатенация строк и т.д.) с операндом NULL должны давать также неопределенное значение NULL. В самом деле, какое значение может иметь, например, NULL+7? Только неопределенное.

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

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

Таблицы истинности для этой трехзначной логики приведены в таблицах 1.4, 1.5, 1.6.

Значения истинности Т-ИСТИНА (TRUE), F-ЛОЖЬ (FALSE), U-НЕИЗВЕСТНО (UNDEFINED). Логическое значение U соответствует пустому значению.

Если вам трудно запомнить таблицы истинности трёхзначной логики, используйте отображение $$F\to0$$, $$T\to1$$, $$U\to0.5$$ и интерпретируйте функции AND, OR, NOT через min, max и 1 — X, соответственно.

Поскольку NULL не входит ни в один из типов данных, для работы с ним вводятся специальные операции. Так, для сравнения с NULL используют не равенство, а операцию "is". Перечислим некоторые её особенности:

Заметим, что в СУБД могут использоваться другие интерпретации неопределённых значений и операций над ними. Обязательно проверьте перечисленные условия при изучении языка SQL в Cache и Oracle.

Как уже сказано, в языках программирования общего назначения неопределенные значения отсутствуют. Поэтому переменная Y, принимающая в базе значение NULL, обычно передается в этих языках двумя переменными Y и YInd. Если Y принимает определенное значение, то значение индикатора YInd равно 0, и можно работать с Y. Если же Y принимает неопределенное значение, то YInd = 1, а значение Y использовать нельзя.

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

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

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

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

По Дейту, реляционная модель состоит из трех частей:

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

Например, в реляционной модели структурная часть образуется отношениями и связями между ними. Единственная структура данных в реляционной модели это рассмотренные выше n-арные отношения, связанные бедным набором связей типов $$1:1$$и $$1:n$$. Подробно эта модель будет рассмотрена в следующих лекциях.

В реализациях СУБД модель данных определяет ещё и способ хранения данных. Современные СУБД используют не менее трёх моделей. Чаще всего это реляционная, одна из объектных и иерархическая модель. Иерархии реализуются расширениями языка базы и часто появляются в связи с использованием XML.

СУБД Cache в этом плане совершенно уникальна. Она использует три модели — объектную, реляционную и иерархическую. Иерархии в ней появляются не только в рамках XML. Персистентный базисный язык Cache, называемый ObjectScript, позволяет работать с древесными данными. Отсутствие в иерархической модели словаря, то есть некоторая незавершённость иерархической модели, предоставляет пользователю широкие возможности для творчества, недоступные в других системах.

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

Именно поэтому в книге так широко используется Cache.

1.2.4 Файловые системы и базы данных

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

В первом приближении можно считать, что базы данных — это надстройка над файловой системой, обеспечивающая работу со сложными структурами данных без явного использования операций с файлами. Система управления базами данных (СУБД) —это программная система, обеспечивающая создание и администрирование базы данных, поддержание целостности содержащихся в ней данных, надежное и эффективное использование ресурсов, предоставление доступа для приложений и пользователей. Эквивалентный английский термин —Data Base Management System (DBMS).

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

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

1.3 База данных как модель бизнеса

1.3.1 Модельный подход

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

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

1.3.2 Бизнес-процессы и данные

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

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

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

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

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

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

1.3.3 Трёхуровневая модель ANSI

Модели реальных баз данных слишком сложны для того, чтобы работать с ними на одном уровне абстракции. В 70-е годы комитет планирования стандартов и норм Национального института Стандартизации США (American National Standard Institute — ANSI) признал необходимость выделения трёх уровней описания элементов данных.

Трёхуровневая архитектура (рисунок 1.6) позволяет отделить:

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

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

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

1.4 Аппаратная реализация

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

Базы данных используют все виды памяти:

В соответствии с традицией термин память означает первичная память.

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

Давайте посмотрим, как устроен жесткий магнитный диск (рисунок 1.8).

Внутри него может быть установлено несколько двусторонних магнитных дисков. Данные со всех поверхностей считываются и записываются на них с помощью магнитных головок, объединённых держателем, перемещаемым с помощью серводвигателя. Диск вращается с постоянной скоростью, измеряемой в оборотах в минуту. Данные на диске организованы в цилиндры, дорожки и секторы. Цилиндры — это наборы дорожек на дисках в виде концентрических окружностей, расположенных одна над другой. Дорожка разделяется на секторы. Минимальная единица данных на диске — сектор.

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

Скорости вращения диска лежат в пределе от 3600 до 7200 об./мин. Существуют более быстрые диски со скоростью около 10-15 тысяч об./мин. Однако, уже при скорости 7200 об./мин возникают проблемы с теплоотводом.

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

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

Для диска со скоростью вращения 3600 об./мин среднее время ожидания сектора, соответствующее половине оборота диска составляет 1/60/2, примерно 8,3 мс. Если учесть время подвода головки, составляющее несколько миллисекунд, приходится признать, что время обращения к диску составляет не менее 10 мс (0, 01 с). А если нужные вам данные находятся на нескольких цилиндрах? А если одновременно с базой работает 100 человек? Придётся ждать от секунд до многих минут.

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

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

Показатель эффективности буфера должен быть как можно ближе к 1. Если, например, $$Hit\_ratio=0.95$$Hlt_ratlo=0.95, то из двадцати обращений к данным только одно вызывает обращение к диску. Остальные данные выбраны из кэша. Практика показывает, что возможны значения Hit_ratio ещё более близкие к единице.

1.5 Определение базы данных

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

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

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

1.6 Что такое администрирование базы данных

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

В этой книге мы почти всегда будем позиционировать себя в качестве разработчиков.

Пользователей можно разделить на два вида:

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

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

Положим вы хотите собрать сведения о пользователях вашего сайта. Пусть на вопрос об имени я ответил "DJVasja". Вы этого запретить мне не можете. А теперь, представьте, что такой фокус выкинул бухгалтер, начисляющий заработную плату. Представили? Мне это трудно вообразить. В дальнейшем изложении будем предполагать, что пользователи всегда обучены и ответственны. И только в лекции 12 допустим другие возможности

Перечислим основные задачи, которые решает администратор базы данных:

В этой книге администрированием мы почти не будем заниматься. Это не наша тема. Так что остаётся надеяться на лучшее, не умея пока преодолевать худшее, и высказать традиционное админское пожелание: "Хороших вам данных!".

1.7 Основные понятия лекции

В заключительной части некоторых лекций курса содержатся семантические сети основных использованных понятий. Они получены бесплатным инструментальным средством CMaps которое можно скачать с сайта http://cmap.ihmc.us/.

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

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

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

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

База данных (разделы 1.1.1 и 1.1.2)

Набор записей (раздел 1.1.3)

Ограничение целостности (раздел 1.2.1)

NULL (раздел 1.2.2)

Схема базы данных (раздел 1.1.4)

Модели данных (раздел 1.2.3)