Современные программные средства обработки информации в большем числе случаев эффективны лишь тогда, когда они способны с приемлемой скоростью обрабатывать большие объемы данных. Даже при высокой скорости современных аппаратных средств, процессоров, которые способны производить миллионы операций в секунду, это не всегда достижимо. Причины этого следующие:
ограниченность объема быстродействующих полупроводниковых устройств памяти (ОЗУ), не позволяющая держать в ОЗУ все данные;
хранение информации на внешних носителях (дисках) вызывает большие задержки в обработке данных, так как диски имеют механические считывающие головки, позиционирование которых занимает время порядка 10 миллисекунд;
последовательный характер работы центральных процессоров, когда практически все действия осуществляются последовательно, выстраиваясь в длинную очередь.
Для решения задачи скоростной обработки больших объемов информации были найдены мощные методы поиска и упорядочения данных:
многоступенчатость поиска;
препроцессорность поиска;
структурирование данных.
Многоступенчатость проявляется в том, что прикладная программа работает не напрямую с большими базами данных, но только с так называемыми индексами или ключами, то есть малой частью объема информации, которая является указателем, где искать целевые данные.
Препроцессорность поиска проявляется в том, что такая малая часть информации подготавливается в виде специальных индексных таблиц или файлов, в которых хранятся не сами данные, но только указатели на них.
К примеру, если мы имеем громадный файл с данными переписи населения страны (это десятки гигабайт), в котором мы собираемся искать данные о конкретном человеке, то на препроцессорном этапе, то есть этапе подготовки базы к последующему многократному поиску создается индексный файл, представляющий собой таблицу с двумя полями: первое – кодовое значение искомой записи, второе – адрес (смещение записи от начала базового файла данных). Эта операция осуществляется один раз для всей следующей за ней серии поисков по базе данных индексированной информации.
Кодовым значением может быть сочетание фамилия + имя + отчество + дата рождения, а в реальных случаях более компактная кодовая величина, вычисляемая из этого сочетания, так называемый “хэш”, однозначно определяемая данным сочетанием.
В процессе индексирования базы находится и записывается во второе поле адрес-смещение или иначе – положение записи в базовом файле соответствующее данному сочетанию, то есть человеку для приводимого примера.
Таким образом на этапе поиска производятся лишь три быстрых операции:
определение индекса или вычисление хэша для искомой записи;
поиск в индексном файле записи с соответствующим значением индекса или хэша и выборка из этой записи в индексном файле адреса целевой записи в базовом файле;
обращение к базовому файлу методом прямого доступа к искомой записи.
Каждая из этих операций занимает ничтожное время по сравнению с прямым перебором записей базового файла. Таким образом, процесс поиска данных ускоряется на много порядков.
Всё это делает программное обеспечение, называемое системой управления базами данных (СУБД).
Что такое СУБД?
Современные авторы часто употребляют термины «банк данных» и «база данных»
как синонимы, однако в общеотраслевых руководящих материалах по созданию банков
данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982
г., эти понятия различаются. Там приводятся следующие определения банка данных,
базы данных и СУБД:
Банк данных
-
это система специальным образом организованных данных - баз данных,
программных, технических, языковых, организационно-методических средств, предназначенных
для обеспечения централизованного накопления и коллективного многоцелевого использования
данных.
База данных, БД
-
именованная совокупность данных, отражающая состояние объектов и их отношений
в рассматриваемой предметной области.
Система управления базами данных, СУБД
-
совокупность языковых и программных средств, предназначенных
для создания, ведения и совместного использования БД многими пользователями.
Сухой канцелярский язык труден для восприятия, но эти определения четко разграничивают назначение всех трех базовых понятий, и мы можем принять их за основу.
Приложение
-
программа, с помощью которой пользователи работают с базой данных.
В общем случае с одной базой данных могут работать множество различных приложений.
Например, если база данных моделирует некоторое предприятие, то для работы с
ней может быть создано приложение, которое обслуживает подсистему учета кадров,
другое приложение может быть посвящено работе подсистемы расчета заработной
платы сотрудников, третье приложение работает как подсистемы складского учета,
четвертое приложение посвящено планированию производственного процесса. При
рассмотрении приложений, работающих с одной базой данных, предполагается, что
они могут работать параллельно и независимо друг от друга, и именно СУБД призвана
обеспечить работу множества приложений с единой базой данных таким образом,
чтобы каждое из них выполнялось корректно, но учитывало все изменения в базе
данных, вносимые другими приложениями.
ПО признаку масштаба можно классифицировать современные СУБД на четыре основных уровня или типа:
Нижний, "нулевой" уровень
СУБД - библиотечный встраиваемый модуль, "движок"
-
эта СУБД представляет собой исполняемую библиотеку, подключаемую к прикладной программе, как например SQLite, являющаяся частью почти любого современного браузера или Borland Database Engine, выполняющая те же функции в продуктах фирмы Borland: Delphi, C++Builder и др., Berkeley DB, используемая в ОС UNIX и часть других СУБД, таких как MySQL.
Первый уровень
Монопольная, "десктоп" СУБД
-
эта СУБД представляет собой обычную прикладную программу, которая используется для однопользовательского использования (монопольного режима), например, MS Access.
Второй уровень
Корпоративная СУБД
-
эта СУБД представляет собой программный комплекс, когда ее предназначением является серверная многопользовательская обработка данных общей для многих пользователей базы данных, например, такие известные продукты, как IBM DB2, Oracle, MySQL, MS SQL-Server, СУБД Progress.
Третий уровень
Гипер-СУБД поисковой системы Интернет
-
эта СУБД представляет собой иерархическую, как минимум, двухуровневую систему управления банком данных, в которой нижний уровень представлен СУБД аналогичными корпоративным, а верхний - "мастер-СУБД", которая осуществляет управление нижним уровнем множества СУБД, кластеризуя большие объемы данных через СУБД нижнего уровня путем перераспределения потоков и объемов информации между СУБД нижнего уровня, но оперируя не первичными данными, а лишь индексной информацией. Примером такой СУБД является распределенная СУБД BigTable корпорации Google.
Рассмотрим основные понятия, употребляемые в технологии баз данных.
Таблица базы данных
-
- совокупность строк и столбцов. Почти полная аналогия с таблицами на бумаге. Важные уточнения: Каждый столбец должен иметь имя, уникальное в пределах этой таблицы. А строки, в теории баз данных, могут следовать в любом порядке, и не имеют номеров. Хотя Delphi, FoxPro и другие добавляют к каждой строке номер, но при выборке данных в SQL, вы его, в общем случае, не получите. Поэтому к каждой строке принято добавлять какой-нибудь идентификатор, для того, чтобы потом можно было легко найти ее.
База данных
-
совокупность таблиц, индексов, хранимых процедур, триггеров и всего остального, что касается нашего проекта. В MS Access, например, так вообще все это в одном файле хранится.
Отношение
-
В реляционной теории баз данных, разделяют понятия таблицы и отношения. Например, в отношении не оговаривается порядок столбцов, а только их набор. Еще для отношений определены ограничения типа невозможности содержать две совершенно одинаковые строки. Различия мы сформулируем в одной фразе: Отношение - довольно абстрактный вид объекта, а таблица - его конкретное изображение. Поэтому мы, в дальнейшем, для упрощения, будем считать, что это одно и то же. Но важно не забывать, что в чистой теории баз данных - это разные понятия.
Ключ
-
Набор столбцов. Он может состоятьиз одного столбца, или охватывать все столбцы таблицы. Для чего нам нужны ключи? Для идентификации строк таблицы. В чистой реляционной теории баз данных это единственный способ сослаться на строку. Ключи бывают разные - потенциальные, первичные, альтенативные, внешние, индексные, хэш-ключи, ключи сортировки, вторичные ключи, ключи шифрование и расшифровки и т.д.
Потенциальный ключ
-
такая комбинацию столбцов, которая обладает следующими свойствами:
Уникальностью. В таблице нет двух разных строк с одиноковыми значениями в нашем потенциальном ключе.
Неизбыточностью. Нельзя убрать один из столбцом из ключа, так, чтобы он не потерял уникальности.
Рассмотрим, например, такую таблицу:
№ паспорта
Фамилия
Имя
Отчество
Должность
123456
Иванов
Иван
Иванович
Директор
234567
Петров
Петр
Иванович
Бухгалтер
345678
Сидорова
Мария
Ивановна
Секретарь
Табличка у нас простая и небольшая. Но нам хватит.
В данной таблице в качестве потенциального ключа можно рассматривать любой столбец. Но она у нас будет расширяться, так что будем смотреть в будущее.
Понятно, что отчество не может быть потенциальным ключом - есть совпадения. Фамилия - может, если только мы не планируем появления новых строк в таблице. Можно взять комбинацию фамилии и должности, врядли у нас будет два директора-однофамильца. Номер паспорта также подходит на роль потенциального ключа. Я думаю вы поняли мою мысль - к каждой конкретной таблице потенциальнх ключей может быть много. Выбор потенциального ключа - дело программиста. Тот же номер паспорта может не подойти, если мы ожидаем кого-нибудь с поддельным паспортом ;) Выбор делается каждый раз заново для каждой ситуации.
Первичные ключи
Первичный ключ, (англ. primary key)
-
в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию). Первичный ключ может быть только один на всю таблицу!
Первичный ключ - это один из потенциальных ключей. Тот, который нам больше понравится. Вам какой больше нравиться? В реальной ситуации, новичок выберет номер паспорта. А что выберет профессионал? Профессионал добавит еще одно поле-счетчик, которое будет содержать уникальное для каждой записи значение. В Delphi такой тип поля называется AutoIncrement, в SQL Server есть целых 2 варианта - TimeStamp и свойтсво Identity поля.
Если в отношении имеется единственный потенциальный ключ, он является и первичным ключом. Если потенциальных ключей несколько, один из них выбирается в качестве первичного, а другие называют “альтернативными”.
С точки зрения теории все потенциальные ключи отношения эквивалентны, то есть обладают одинаковыми свойствами уникальности и минимальности. Однако в качестве первичного обычно выбирается тот из потенциальных ключей, который наиболее удобен для тех или иных практических целей, например для создания внешних ключей в других отношениях либо для создания кластерного индекса. Поэтому в качестве первичного ключа, как правило, выбирают тот, который имеет наименьший размер (физического хранения) и/или включает наименьшее количество атрибутов.
Исторически термин “первичный ключ” появился и стал использоваться существенно ранее термина “потенциальный ключ”. Вследствие этого множество определений в реляционной теории были изначально сформулированы с упоминанием первичного (а не потенциального) ключа, например, определения нормальных форм. Так же термин “первичный ключ” вошёл в формулировку 12 правил Кодда как основной способ адресации любого значения отношения (таблицы) наряду с именем отношения (таблицы) и именем атрибута (столбца).
Альтернативный ключ
-
После выбора первичного ключа из набора потенциальных ключей, оставшиеся ключи называются альтернативными.
Внешний ключ
-
это ключ, расшифровка которого лежит в другой таблице.
Эта тема тесно связана со следующей - "Некоторые правилами построения баз данных" В частности с понятием нормализации Это будет потом, а сейчас только некоторые моменты.
Когда мы создаем какую-нибудь базу данных, например, для начисления зарплаты, нам не удобно всех работников упоминать в одной таблице. Если, например, какой-нибудь из них упоминается там не один раз (зарплата, премия, надбавки, снятия, налоги и пр.), то при изменении его/ее фамилии надо будет пробежаться по всем строкам, и поменять все вхождения. Это неудобно. Есть и другие поводы разделить такую таблицу.
Итак, имеем две таблицы:
Код работника
Вид движения
Сумма
1
Оклад
100
1
Премия
30
1
Налоги
-25
2
Оклад
90
...
...
...
Код работника
Фамилия
Имя
Отчество
1
Иванов
Иван
Иванович
2
Петров
Петр
Иванович
3
Сидорова
Мария
Ивановна
В первой таблице - с деньгами - столбец "Код работника" называется внешним ключом. Ясно, что он не может существовать без соответствующей строки из второй таблицы, в которой столбец "Код работника" - уже знакомый нам обычный первичный ключ. Вторая таблица - с фамилиями - является как бы "справочником фамилий" для первой.
Хотя чистая реляционная теория требует, чтобы внешние ключи всегда ссылались на первичные ключи, мы это требование низведем до простой рекомендации: бывают ситуации, когда одна и та же таблица может служить справочником разным другим, причем в разном качестве. А первичный ключ, как мы знаем, может быть только один.
Ранее мы обошли вопрос "А что будет, если не найдется работника с кодом, который мы использовали?" Ничего хорошего не будет. Такой ситуации надо всячески избегать, так как при этом возникнут сбои в нашей программе.
Ссылочная целостность, Refential Integrity
-
такое состояние, когда у нас все что надо правильно находится. Контроль ссылочной целостности - обеспечение такого состояния.
А если пользователь захочет удалить одно из работников? По ситуации смотреть надо - когда просто запретить такие действия, когда удалить все соответствующие записи из другой таблицы (так называемое "каскадное удаление"). Этот момент очень важен - ни при каких ситуациях нельзя допускать нарушения ссылочной целостности.
Простой ключ
-
это первичный ключ, состоящий из единственного атрибута.
Составной ключ
-
Если первичный ключ состоит из двух и более атрибутов, его называют составным ключом.
Так, номер паспорта и серия паспорта не могут быть первичными ключами по отдельности, так как могут оказаться одинаковыми у двух и более людей. Но не бывает двух личных документов одного типа с одинаковыми серией и номером. Поэтому в отношении, содержащем данные о людях, первичным ключом может быть подмножество атрибутов, состоящее из типа личного документа, его серии и номера.
Суррогатный ключ
-
понятие теории реляционных баз данных. Это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого - служить первичным ключом. Значение этого поля не образуется на основе каких-либо других данных из БД, а генерируется искусственно.
Знаете ли Вы, почему "черные дыры" - фикция? Согласно релятивистской мифологии, "чёрная дыра - это область в пространстве-времени, гравитационное притяжение которой настолько велико, что покинуть её не могут даже объекты, движущиеся со скоростью света (в том числе и кванты самого света). Граница этой области называется горизонтом событий, а её характерный размер - гравитационным радиусом. В простейшем случае сферически симметричной чёрной дыры он равен радиусу Шварцшильда". На самом деле миф о черных дырах есть порождение мифа о фотоне - пушечном ядре. Этот миф родился еще в античные времена. Математическое развитие он получил в трудах Исаака Ньютона в виде корпускулярной теории света. Корпускуле света приписывалась масса. Из этого следовало, что при высоких ускорениях свободного падения возможен поворот траектории луча света вспять, по параболе, как это происходит с пушечным ядром в гравитационном поле Земли. Отсюда родились сказки о "радиусе Шварцшильда", "черных дырах Хокинга" и прочих безудержных фантазиях пропагандистов релятивизма. Впрочем, эти сказки несколько древнее. В 1795 году математик Пьер Симон Лаплас писал: "Если бы диаметр светящейся звезды с той же плотностью, что и Земля, в 250 раз превосходил бы диаметр Солнца, то вследствие притяжения звезды ни один из испущенных ею лучей не смог бы дойти до нас; следовательно, не исключено, что самые большие из светящихся тел по этой причине являются невидимыми." [цитата по Брагинский В.Б., Полнарёв А. Г. Удивительная гравитация. - М., Наука, 1985] Однако, как выяснилось в 20-м веке, фотон не обладает массой и не может взаимодействовать с гравитационным полем как весомое вещество. Фотон - это квантованная электромагнитная волна, то есть даже не объект, а процесс. А процессы не могут иметь веса, так как они не являются вещественными объектами. Это всего-лишь движение некоторой среды. (сравните с аналогами: движение воды, движение воздуха, колебания почвы). Подробнее читайте в FAQ по эфирной физике.
