Базы Данных, 04 лекция (от 15 сентября)
Материал из ESyr's Wiki pages.
Базы данных 15.09.06
В следующий четверг Соловьёв
Следующим шагом являетмся написание сециального языка, аозволяющего управлять данными, но который не зависит от структуры баз данных.
Нельзя считать, что Эдгар Кодд был основателем БД. До реляционных БД появились другие типы БД. Было три направления, которые в последствии назывались моделями данных, а тогда назывались технологиями.
Иерархическая технология. БД представлялась в виде древовидной структуры, в корне сидели однотипные структуры, у которых могли быть свои ветви. Главным ограничением древовидной структуры является наличие у потомка только одного предка. С одной стороны, икерархия – вещь необходимая. Постоянно пишутся стотьи, в которых показывается, как моделировать цдревовидные структуры. На самом деле ограничение на количество предков – достаточно серьёзное. Человек может одновременно работать в отделе 33, заниматься дзюдо, ходить в джаззовый клуб и быть членом, как это не стыдно сказать, лдпр.
IMS (IBM) – одна из заслуженных СУБД. Уже в 1974 году считалась старой, но тем не менее, она ещё жива.
Сетевая организация. Принципиальным отличием явлдяется возможность налиция нескольких предков. Чем замечательна сетевая организация 0 для таких систем был создан первый стандарт, под названием стандарт CODASEL. Он явдялся частью организации по стандартизации Кобола, который занялся стандартизацией БД.
Наши люди: Михаил Рувимович Коголовский – заслуженный человек, единственный после Дидро, кто единолично написал энциклопедию, энциклопедию по БД.
Представителем сетевых СУБД является IDMS (Computer Associates). В конце прошлого века лектор ездил несколько раз на конференции СА, на которых обсуждались все поддерживаемые компании технологии. Эти конференции собирали тысячи человек.
Инвертированные таблицы.
Adabas (Software AG) – дико популярная в СССР система. Нужно знать, что она именно этой структуры, так как в последнее время к ней было прикручено много винтиков, которые делают её похожие на реляционные СУБД
Cache (InterSystems) построена на реляционной М-технологии
У DEC был MUMPS – интерпретируемый коммандный язык, который был сделан под PDP-11. Как и в Perl, где много различных заготовок, в MUMPS была система работы с данными, в частности, с B-деревьями. От неё были технологии, которые использовали B-деревья. В частности, Cache.
Языка не было. Библиотеки педоставляли функцие, которые позволяли осуществлять навигацию. Это был уровень ассемблера, так как всё делалось только при помощи переходов (goto). Ещё одной отрицательной стороной являлось то, что бизнес-логика перемежалась с этими низкоуровневыми вызовами.
Панацеей стал SQL, который стал общеприняым способов формирования запросов.
Пример: нужно получить общую численность отдела, где работает определённый человек.
SELECT ОТД_РАЗМЕР
FROM СЛУЖАЩИЕ, ОТДЕЛЫ
WHERE СЛУ_ИМЯ=«П. И. Сидоров»
AND СЛУ_ОТДЕЛ=ОТД_НОМЕР
Эти запросы относятся к классу запросов с полусоединением. Данные используются из двух файлов, но данные берутся из таблицы отделов. Проргамма могла бы выглядеть так: просматриваем записи служащих, находим запись, где имя есть Сидоров, вытаскиваем имя отдела и находим этот отдел по номеру в таблице отделов.
Другой вариант записи запроса (запрос с подзапросом):
SELECT ОТД_РАЗМЕР
FROM ОТДЕЛЫ
WHERE ОТД_НОМЕР =
( SELECT СЛУ_ОТД_НОМЕР
FROM СЛУЖАЩИЕ
WHERE СЛУ_ИМЯ= «П. И. Сидоров» )
SQL не является чисто функциональным, в отличие от языка запроса к XML-данным Exquiry.
Такой способ формулировки запросов хорош тем, что если при старом способе написания запросов при появлении новых требований приходится писать программу. И пользователь не зависит от того, как система выполняет запрос.
Предыдущие примеры показывают, что при работе данными требуются более высокие средства, чем набор функций.
Следующий
пример: приём новых служащий – нужно добавить записьь в таблицу
служащих и изменить щапись в таблице обменов. Во время любой из этих
операций может произойти сбой системы. Например, произошёл сбой
системы. Или выключилось питание. Полетели диски. Требуется, что
после дополнительных служебных действий возмодно было привести файлы
в предыдущее непротиворечивое состояние. И в каком порядке мы бы не
стали их менять, существует место, в котором может произоти сбой,
когда данные в противоречивом состоянии. СистемЫ, которые заботятся о
пользователях, беруд служебные фунуции на себя. Наиболее
распространённым способом является журналирование, которое позволяет
после сбоя привести систему в последнее непротиворечивое состояние. С
этим понятием связано понятие транзакции. Одним из свойств транзакции
является сохранение целостности - Consistency.
ACID-свойства:
Atomicy – атомичность – транзакция или проходит, или не проходит, третьего не дано
Consistency – целостонсть – сохранение целостности до и после транзакции
Isolation – изолированность – нельзя зафиксировать внутреннее состояние транзакции
Durability – долговременность – после подтверждения транзакции её нельзя отменить
Цель, которую должна преследовать многопольз система – каждый полдьзователь, каждая система работает так, как будто бы она одна.
Понятие транзакции является хорошим, практически иделальным средством изоляции пользовтаелей.
Теперь видно, что картинка БД_14_09_06_рис3 не годится. Тогда получим БД_15_09_06_рис2, которая не годится при смене структуры БД. В результате получим БД_15_09_06_рис3. В результате приходим к клиент-серверной модели.
Право на жизнь имеют и ФС, и СУБД. Лектор горячий противник M$ скрестить ФС и SQL Server, которая пытается заменить простой и надёжный способ управления файлами, громохдким и сложным механизмом СУБД с той же функциональностью.
Важным компонентом метаданных является то, что любая БД, устроенная таким образом, является самоописанной. Есть поля, ограничения... и всё это хранится в метаданных. И заслуга SQL в том, что метаданные также доступны, как и обычные данные.
До этого существовала система управления словарями-справочниками, и СУБД пользовалась ей.
Оказывается, что метаданные удобно хранить в виде таблицы.
Экстенсиональные – данные, которые доступны пользователю
Интенсиональные – внутреннние данные для системы и помогают её работе.
Вводная часть закончилась.
Тема 1. Введение в реляционную модель данных (ориентировочно до 10 октября).
Эдгар Кодд умер в 2004 году.
Самое великое достижение Кодда – введение в обиход реляционной модели данных. Самая первая публикация появилась в 1974. году. Лектор может гордится тем, что в течение 4 лет издавался журнал СУБД (1994-1998), где, тем не менее, были переводы почти всех статей. (osp.ru – архив открытые системы – субд) Переводчиком был Коголовский.
У кодда был этап, когда он хотел усовершенствовать реляционную модель данных, но в жизнь результат не пошёл.
Родом Кодд из IBM.
В той части мира, где проживает лектор (человек 10), мир воспринимается глазами не Кодда, а Кристофера Дейты.
Citforum.ru – бд – десяток или полтора статей по этому поводу.
К сожалению, излагаемая модель есть мешанина и её очень трудно найти в какой-либо книге.
Единственная правильная система от M$ - SQL Server 2005.
В заключение сегодняшней лекции, основные достоинстав рел подхода
Основывается на небольшом числе интуитивно понятных абстракций
В основе рел подхода лежит очень мощный и очень простой математический аппарат. Рел модель позволила создать рел алгебру. Лектор считает, что рел модель завоевала мир благодаря своей алгебре.
Рел подход обеспечивает возмодность ненавигационную возможнось манипулирования
Лектор ругает широкие массы. Американец написал статью про важность ссылочной целостность, из которой следует, что американцы не знают, что такое ссылочная целостность. После чего лектор решил пожаловаться знакомым и один из них сказал, что наши тоже не знают, что такое ссылочная целостность, они её боятся, боятся, что система будет следить за этим. Что противоречит идее Кодда, при которой забота о целостности должна быть переложена на систему.
