Материал из eSyr's wiki.

Предыдущая лекция | Следующая лекция

Введение

До реляционных БД

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

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

• Иерархическая технология.
  • Пример: IMS (IBM) – одна из заслуженных СУБД. Уже в 1974 году считалась старой, но тем не менее, она ещё жива.
  • БД представлялась в виде древовидной структуры, в корне сидели однотипные структуры, у которых могли быть свои ветви.
  • Главным ограничением древовидной структуры является наличие у потомка только одного предка. С одной стороны, иерархия – вещь необходимая. Постоянно пишутся статьи, в которых показывается, как моделировать древовидные структуры. На самом деле ограничение на количество предков – достаточно серьёзное.

Человек может одновременно работать в отделе 33, заниматься дзюдо,
ходить в джаззовый клуб и быть членом, как это не стыдно сказать, ЛДПР.

• Сетевая организация.
  • Пример: IDMS (Computer Associates). В конце прошлого века лектор ездил несколько раз на конференции СА, на которых обсуждались все поддерживаемые компании технологии. Эти конференции собирали тысячи человек.
  • Принципиальным отличием является возможность наличия нескольких предков. Чем замечательна сетевая организация для таких систем был создан первый стандарт, под названием стандарт CODASEL. Он являлся частью организации по стандартизации COBOL, который занялся стандартизацией БД
  • Наши люди: Михаил Рувимович Коголовский – заслуженный человек, единственный после Дидро, кто единолично написал энциклопедию, энциклопедию по БД.

• Инвертированные таблицы.
  • Пример: Adabas (Software AG) – дико популярная в СССР система. Нужно знать, что она именно этой структуры, так как в последнее время к ней было прикручено много винтиков, которые делают её похожие на реляционные СУБД

• Cache (InterSystems) построена на реляционной М-технологии
  • У DEC был MUMPS – интерпретируемый коммандный язык, который был сделан под PDP-11. Как и в Perl, где много различных заготовок, в MUMPS была система работы с данными, в частности, с B-деревьями. От неё были технологии, которые использовали B-деревья. В частности, Cache.

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

Панацея - SQL

Формирование запросов

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

• Пример: нужно получить общую численность отдела, где работает определённый человек.

(SQL)
SELECT ОТД_РАЗМЕР 
FROM СЛУЖАЩИЕ, ОТДЕЛЫ
WHERE СЛУ_ИМЯ=«П. И. Сидоров»
    AND СЛУ_ОТДЕЛ=ОТД_НОМЕР

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

В SQL всегда есть десятки способов сформулировать запрос.

• Запрос с подзапросом:

(SQL)
SELECT ОТД_РАЗМЕР
FROM ОТДЕЛЫ
WHERE ОТД_НОМЕР =
    (SELECT СЛУ_ОТД_НОМЕР FROM СЛУЖАЩИЕ
      WHERE СЛУ_ИМЯ = «П. И. Сидоров» )

SQL не является чисто функциональным, в отличие от языка запроса к XML-данным Exquiry.

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

Транзакции

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

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

С этим понятием связано понятие транзакции. Одним из свойств транзакции является сохранение целостности - Consistency.

Транзакция - набор команд, которые удовлетворяют следующим свойствам (ACID-свойства):

• Atomicy – атомичность – транзакция или проходит целиком, или не проходит, третьего не дано
• Consistency – целостность – сохранение целостности до и после транзакции
• Isolation – изолированность – нельзя зафиксировать внутреннее состояние транзакции
• Durability – долговременность – после подтверждения транзакции её нельзя отменить, результаты останутся

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

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

Метаданные (Я УМЫВАЮ РУКИ)

(О_О")
Теперь видно, что картинка БД_14_09_06_рис3 не годится.
Тогда получим БД_15_09_06_рис2, которая не годится при смене
структуры БД. В результате получим БД_15_09_06_рис3.
В результате приходим к клиент-серверной модели.

(надпись рядом с одной из картинок ZOK'a)
СУБД и метаданные диффундировали и прийдется
все переделывать при расширении метаданных

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

Важным компонентом метаданных является то, что любая БД, устроенная таким образом, является самоописанной. Есть поля, ограничения... и всё это хранится в метаданных. И заслуга SQL в том, что метаданные также доступны, как и обычные данные.

До этого существовала система управления словарями-справочниками, и СУБД пользовалась ей.

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

• Интенсиональные – внутреннние данные для системы, сокрытые от пользователя и помогают работе системы
• Экстенсиональные – данные, которые доступны пользователю

Вводная часть закончилась.

Тема 1. Введение в реляционную модель данных

Эдгар Кодд умер в 2004 году.

Самое великое достижение Кодда – введение в обиход реляционной модели данных. Самая первая публикация появилась в 1974. году. Лектор может гордится тем, что в течение 4 лет издавался журнал СУБД (1994-1998), где, тем не менее, были переводы почти всех статей. (osp.ru – архив открытые системы – субд) Переводчиком был Коголовский.

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

Родом Кодд из IBM.

http://citforum.ru – БД – десяток или полтора статей по этому поводу (точный адрес http://citforum.ru/database/articles/index.shtml).

В заключение сегодняшней лекции, отметим основные достоинства реляционного подхода:

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