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

Текст из файла (страница 3)

Языка не было. Библиотеки педоставляли функцие, которые позволяли осуществлять навигацию. Это был уровень ассемблера, так как всё делалось только при помощи переходов (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.

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

1. Основывается на небольшом числе интуитивно понятных абстракций

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

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

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

Базы данных 22.09.06

Лектор рассказывает своё представление о реляционной модели, отличное, как от Кодда, так и от Дейты.

Не было понятия реляционной модели до реляционной модели Кодда.

Реляционная модель данных

Модель данных — совокупность следующих компонент:

1. Совокупность типов данных, с которыми можно работать. Пример: есть только булевские типы, и на них всё строится. Если посмотреть, какие сейчас модели данных существуют, есть реляционные, объектно-ориентированные, объектно-реляционные, и у них у всех модели совпадают, и встроенные типы данных одни и те же, механизмы наследования похожи... Что их различает? Появляется понятие переменных, и речь идёт о долговременных (persistent) переменных — переменных, которые сохраняют свои значение вплоть до завершения программы, которая их создала. И всё отличие этих трёх моделей, (объектно реляционной лектор будет называть SQL) в том, какие переменные могут храниться в БД. В ОО БД могут хранится переменные любого типа, в реляционных только типа отношения. В объектно-реляционных БД тип мультимножества. Во всех трёх моделях тип мультимножества не запрещается, вопрос в том, виден ли он наверху как набор данных, с которыми работает пользователь. И от Дейты структурная составляющая модели данных.

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

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

2. Операции определяются отдельно от данных

), литералы или представление значений (требуется, когда необходимо написать какою-то переменную типа. У Дейты показано, что литерал означает немного другое, что при написании 3.14 я хочу выбрать значение типа, у которого такое представление, то есть это операция, и у Дейты есть оператор SELECT).

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

БД в реляционной модели данных представляет собой конечный набор переменных типа отношение — краткое содержание структурной части.

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

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

Лектор рассматривает подмножество надмножества алгебры Кодда

Тип отношения — множество пар, которые включают два компонента – имя атрибута и тип данных этого атрибута. Одно ограничение — требуется, чтобы в этом множестве первые элементы были различны. Обозначение: {<A, T>}

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

А, лектор не выключил звук мобильного!

В современном понимании реляционной модели это может быть любой тип данных.

Надо ещё понимать, что такое значение отношения.

Кортеж — множество упорядоченных троек: атрибут, тип (домен), значение. Обозначение: {<A, T, V>}

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

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

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

Типы отношения это множество, и поэтому любое подмножество типа отношения является типом отношения. И кортеж это множество, и любое подмножество кортежа является кортежем.

Типы отношений анонимны.

Есть Дмитрий Б. Подшивалов — известный человек. Он в своё время был редактором перевода книжки Вирта про Модулу2, написал послесловие, у там есть пассаж относительно вреда структурной эквивалентности типов, оно поражает многочисленные трудности при реализации и не даёт никакой свободы. В SQL нет возможности определить заголовок таблицы до CREATE TABLE, хотя на самом деле в реальных БД есть таблицы, у которых одинаковые заголовки.

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

Переменные отношения (relvar — relation variable) — переменная некоего типа отношение, которая хранит (...).

БД – конечный набор переменных отношения (?)

Лектор обозначает отношением и тип отношение, и значение типа отношения, в зависимости от контекста

Единственное требование — хранимые в БД данные должны быть типизированы.

Чем отличаются relvar от обыкновенных переменных — если обыкновенные переменные нельзя не инициализировать перед использованием, то при работе с БД, когда имеем отношение с контейнерами, широкая таблица, и сплошь и рядом пытаемся собрать все возможные данные, например, БД военно-учётного стола, и там должно быть очень много данных, тем не менее, когда человека приписывают, как правило, про него известно не всё, например, какой человек скажет, что одна нога короче другой, а данные хранить в базе нужно, и для того, чтобы можно было бороться с проблемой отсутствующей информации, Кодд же предложил ввести одно псевдозначение, которое называется NULL, оно не является членом какого-либо типа данных, и может использоваться в любой операции, где может использоваться какое-то значения типа данных, причём оно обладает следующими свойствами: в русском языке оно называется неопределенным значением, что неправильно, так как это псевдозначение. Так вот, для любого значения А типа Т A op NULL ≡ NULL op A ≡ NULL op NULL ≡ NULL. Для логических операций A comp_op NULL ≡ NULL comp_op A ≡ NULL comp_op NULL ≡ unknown.

Характеристики

Список файлов лекций