Названия реляционных баз данных. Основные положения реляционной модели БД
- Перевод
Примечание переводчика: хоть статья довольно старая (опубликована 2 года назад) и носит громкое название, в ней все же дается хорошее представление о различиях реляционных БД и NoSQL БД, их преимуществах и недостатках, а также приводится краткий обзор нереляционных хранилищ.
В последнее время появилось много нереляционных баз данных. Это говорит о том, что если вам нужна практически неограниченная масштабируемость по требованию, вам нужна нереляционная БД.
Если это правда, значит ли это, что могучие реляционные БД стали уязвимы? Значит ли это, что дни реляционных БД проходят и скоро совсем пройдут? В этой статье мы рассмотрим популярное течение нереляционных баз данных применительно к различным ситуациям и посмотрим, повлияет ли это на будущее реляционных БД.
Реляционные базы данных существуют уже около 30 лет. За это время вспыхивало несколько революций, которые должны были положить конец реляционным хранилищам. Конечно, ни одна из этих революций не состоялась, и одна из них ни на йоту не поколебала позиции реляционных БД.
Начнем с основ
Реляционная база данных представляет собой набор таблиц (сущностей). Таблицы состоят из колонок и строк (кортежей). Внутри таблиц могут быть определены ограничения, между таблицами существуют отношения. При помощи SQL можно выполнять запросы, которые возвращают наборы данных, получаемых из одной или нескольких таблиц. В рамках одного запроса данные получаются из нескольких таблиц путем их соединения (JOIN), чаще всего для соединения используются те же колонки, которые определяют отношения между таблицами. Нормализация - это процесс структурирования модели данных, обеспечивающий связность и отсутствие избыточности в данных.
Доступ к реляционным базам данных осуществляется через реляционные системы управления базами данных (РСУБД). Почти все системы баз данных, которые мы используем, являются реляционными, такие как Oracle, SQL Server, MySQL, Sybase, DB2, TeraData и так далее.
Причины такого доминирования неочевидны. На протяжении всего существования реляционных БД они постоянно предлагали наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости в сфере управлении данными.
Однако чтобы обеспечить все эти особенности, реляционные хранилища невероятно сложны внутри. Например, простой SELECT запрос может иметь сотни потенциальных путей выполнения, которые оптимизатор оценит непосредственно во время выполнения запроса. Все это скрыто от пользователей, однако внутри РСУБД создает план выполнения, основывающийся на вещах вроде алгоритмов оценки стоимости и наилучшим образом отвечающий запросу.
Проблемы реляционных БД
Хотя реляционные хранилища и обеспечивают наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости, их показатели по каждому из этих пунктов не обязательно выше, чем у аналогичных систем, ориентированных на какую-то одну особенность. Это не являлось большой проблемой, поскольку всеобщее доминирование реляционных СУБД перевешивало какие-либо недочеты. Тем не менее, если обычные РБД не отвечали потребностям, всегда существовали альтернативы.Сегодня ситуация немного другая. Разнообразие приложений растет, а с ним растет и важность перечисленных особенностей. И с ростом количества баз данных, одна особенность начинает затмевать все другие. Это масштабируемость. Поскольку все больше приложений работают в условиях высокой нагрузки, например, таких как веб-сервисы, их требования к масштабируемости могут очень быстро меняться и сильно расти. Первую проблему может быть очень сложно разрешить, если у вас есть реляционная БД, расположенная на собственном сервере. Предположим, нагрузка на сервер за ночь увеличилась втрое. Как быстро вы сможете проапгрейдить железо? Решение второй проблемы также вызывает трудности в случае использования реляционных БД.
Реляционные БД хорошо масштабируются только в том случае, если располагаются на единственном сервере. Когда ресурсы этого сервера закончатся, вам необходимо будет добавить больше машин и распределить нагрузку между ними. И вот тут сложность реляционных БД начинает играть против масштабируемости. Если вы попробуете увеличить количество серверов не до нескольких штук, а до сотни или тысячи, сложность возрастет на порядок, и характеристики, которые делают реляционные БД такими привлекательными, стремительно снижают к нулю шансы использовать их в качестве платформы для больших распределенных систем.
Чтобы оставаться конкурентоспособными, вендорам облачных сервисов приходится как-то бороться с этим ограничением, потому что какая ж это облачная платформа без масштабируемого хранилища данных. Поэтому у вендоров остается только один вариант, если они хотят предоставлять пользователям масштабируемое место для хранения данных. Нужно применять другие типы баз данных, которые обладают более высокой способностью к масштабированию, пусть и ценой других возможностей, доступных в реляционных БД.
Эти преимущества, а также существующий спрос на них, привел к волне новых систем управления базами данных.
Новая волна
Такой тип баз данных принято называть хранилище типа ключ-значение (key-value store). Фактически, никакого официального названия не существует, поэтому вы можете встретить его в контексте документо-ориентированных, атрибутно-ориентированных, распределенных баз данных (хотя они также могут быть реляционными), шардированных упорядоченных массивов (sharded sorted arrays), распределенных хэш-таблиц и хранилищ типа ключ-значения. И хотя каждое из этих названий указывает на конкретные особенности системы, все они являются вариациями на тему, которую мы будем назвать хранилище типа ключ-значение.Впрочем, как бы вы его не называли, этот «новый» тип баз данных не такой уж новый и всегда применялся в основном для приложений, для которых использование реляционных БД было бы непригодно. Однако без потребности веба и «облака» в масштабируемости, эти системы оставались не сильно востребованными. Теперь же задача состоит в том, чтобы определить, какой тип хранилища больше подходит для конкретной системы.
Реляционные БД и хранилища типа ключ-значение отличаются коренным образом и предназначены для решения разных задач. Сравнение характеристик позволит всего лишь понять разницу между ними, однако начнем с этого:
Характеристики хранилищ
| Реляционная БД | Хранилище типа ключ-значение |
|---|---|
| База данных состоит из таблиц, таблицы содержат колонки и строки, а строки состоят из значений колонок. Все строки одной таблицы имеют единую структуру. |
Для доменов можно провести аналогию с таблицами, однако в отличие от таблиц для доменов не определяется структура данных. Домен – это такая коробка, в которую вы можете складывать все что угодно. Записи внутри одного домена могут иметь разную структуру. |
| Модель данных 1 определена заранее. Является строго типизированной, содержит ограничения и отношения для обеспечения целостности данных. |
Записи идентифицируются по ключу, при этом каждая запись имеет динамический набор атрибутов, связанных с ней. |
| Модель данных основана на естественном представлении содержащихся данных, а не на функциональности приложения. |
В некоторых реализация атрибуты могут быть только строковыми. В других реализациях атрибуты имеют простые типы данных, которые отражают типы, использующиеся в программировании: целые числа, массива строк и списки. |
| Модель данных подвергается нормализации, чтобы избежать дублирования данных. Нормализация порождает отношения между таблицами. Отношения связывают данные разных таблиц. |
Между доменами, также как и внутри одного домена, отношения явно не определены. |
Никаких join’ов
Хранилища типа ключ-значение ориентированы на работу с записями. Это значит, что вся информация, относящаяся к данной записи, хранится вместе с ней. Домен (о котором вы можете думать как о таблице) может содержать бессчетное количество различных записей. Например, домен может содержать информацию о клиентах и о заказах. Это означает, что данные, как правило, дублируются между разными доменами. Это приемлемый подход, поскольку дисковое пространство дешево. Главное, что он позволяет все связанные данные хранить в одном месте, что улучшает масштабируемость, поскольку исчезает необходимость соединять данные из различных таблиц. При использовании реляционной БД, потребовалось бы использовать соединения, чтобы сгруппировать в одном месте нужную информацию.
Хотя для хранения пар ключ-значение потребность в отношения резко падает, отношения все же нужны. Такие отношения обычно существуют между основными сущностями. Например, система заказов имела бы записи, которые содержат данные о покупателях, товарах и заказах. При этом неважно, находятся ли эти данные в одном домене или в нескольких. Суть в том, что когда покупатель размещает заказ, вам скорее всего не захочется хранить информацию о покупателе и о заказе в одной записи.
Вместо этого, запись о заказе должна содержать ключи, которые указывают на соответствующие записи о покупателе и товаре. Поскольку в записях можно хранить любую информацию, а отношения не определены в самой модели данных, система управления базой данных не сможет проконтролировать целостность отношений. Это значит, что вы можете удалять покупателей и товары, которые они заказывали. Обеспечение целостности данных целиком ложится на приложение.
Доступ к данным
| Реляционная БД | Хранилище типа ключ-значение |
|---|---|
| Данные создаются, обновляются, удаляются и запрашиваются с использованием языка структурированных запросов (SQL). |
Данные создаются, обновляются, удаляются и запрашиваются с использованием вызова API методов. |
| SQL-запросы могут извлекать данные как из одиночной таблица, так и из нескольких таблиц, используя при этом соединения (join’ы). |
Некоторые реализации предоставляют SQL-подобный синтаксис для задания условий фильтрации. |
| SQL-запросы могут включать агрегации и сложные фильтры. |
Зачастую можно использовать только базовые операторы сравнений (=, !=, <, >, <= и =>). |
| Реляционная БД обычно содержит встроенную логику, такую как триггеры, хранимые процедуры и функции. |
Вся бизнес-логика и логика для поддержки целостности данных содержится в коде приложений. |
Взаимодействие с приложениями
Хранилища типа ключ-значение: преимущества
Есть два четких преимущества таких систем перед реляционными хранилищами.Подходят для облачных сервисов
Первое преимущество хранилищ типа ключ-значение состоит в том, что они проще, а значит обладают большей масштабируемостью, чем реляционные БД. Если вы размещаете вместе собственную систему, и планируете разместить дюжину или сотню серверов, которым потребуется справляться с возрастающей нагрузкой, за вашим хранилищем данных, тогда ваш выбор – хранилища типа ключ-значение.Благодаря тому, что такие хранилища легко и динамически расширяются, они также пригодятся вендорам, которые предоставляют многопользовательскую веб-платформу хранения данных. Такая база представляет относительно дешевое средство хранения данных с большим потенциалом к масштабируемости. Пользователи обычно платят только за то, что они используют, однако их потребности могут вырасти. Вендор сможет динамически и практически без ограничений увеличить размер платформы, исходя из нагрузки.
Более естественная интеграция с кодом
Реляционная модель данных и объектная модель кода обычно строятся по-разному, что ведет к некоторой несовместимости. Разработчики решают эту проблему при помощи написания кода, который отображает реляционную модель в объектную модель. Этот процесс не имеет четкой и быстро достижимой ценности и может занять довольно значительное время, которое могло быть потрачено на разработку самого приложения. Тем временем многие хранилища типа ключ-значение хранят данные в такой структуре, которая отображается в объекты более естественно. Это может существенно уменьшить время разработки.Другие аргументы в пользу использования хранилищ типа ключ-значение, наподобие «Реляционные базы могут стать неуклюжими» (кстати, я без понятия, что это значит), являются менее убедительными. Но прежде чем стать сторонником таких хранилищ, ознакомьтесь со следующим разделом.
Хранилища типа ключ-значение: недостатки
Ограничения в реляционных БД гарантируют целостность данных на самом низком уровне. Данные, которые не удовлетворяют ограничениям, физически не могут попасть в базу. В хранилищах типа ключ-значение таких ограничений нет, поэтому контроль целостности данных полностью лежит на приложениях. Однако в любом коде есть ошибки. Если ошибки в правильно спроектированной реляционной БД обычно не ведут к проблемам целостности данных, то ошибки в хранилищах типа ключ-значение обычно приводят к таким проблемам.Другое преимущество реляционных БД заключается в том, что они вынуждают вас пройти через процесс разработки модели данных. Если вы хорошо спроектировали модель, то база данных будет содержать логическую структуру, которая полностью отражает структуру хранимых данных, однако расходится со структурой приложения. Таким образом, данные становятся независимы от приложения. Это значит, что другое приложение сможет использовать те же самые данные и логика приложения может быть изменена без каких-либо изменений в модели базы. Чтобы проделать то же самое с хранилищем типа ключ-значение, попробуйте заменить процесс проектирования реляционной модели проектированием классов, при котором создаются общие классы, основанные на естественной структуре данных.
И не забудьте о совместимости. В отличие от реляционных БД, хранилища, ориентированные на использование в «облаке», имеют гораздо меньше общих стандартов. Хоть концептуально они и не отличаются, они все имеют разные API, интерфейсы запросов и свою специфику. Поэтому вам лучше доверять вашему вендору, потому что в случае чего, вы не сможете легко переключиться на другого поставщика услуг. А учитывая тот факт, что почти все современные хранилища типа ключ-значение находятся в стадии бета-версий 2 , доверять становится еще рискованнее, чем в случае использования реляционных БД.
Ограниченная аналитика данных
Обычно все облачные хранилища строятся по типу множественной аренды , что означает, что одну и ту же систему использует большое количество пользователей и приложений. Чтобы предотвратить «захват» общей системы, вендоры обычно каким-то образом ограничивают выполнение запросов. Например, в SimpleDB запрос не может выполняться дольше 5 секунд. В Google AppEngine Datastore за один запрос нельзя получить больше, чем 1000 записей 3 .Эти ограничения не страшны для простой логики (создание, обновление, удаление и извлечение небольшого количества записей). Но что если ваше приложение становится популярным? Вы получили много новых пользователей и много новых данных, и теперь хотите сделать новые возможности для пользователей или каким-то образом извлечь выгоду из данных. Тут вы можете жестко обломаться с выполнением даже простых запросов для анализа данных. Фичи наподобие отслеживания шаблонов использования приложения или системы рекомендаций, основанной на истории пользователя, в лучшем случае могут оказаться сложны в реализации. А в худшем - просто невозможны.
В таком случае для аналитики лучше сделать отдельную базу данных, которая будет заполняться данными из вашего хранилища типа ключ-значение. Продумайте заранее, каким образом это можно будет сделать. Будете ли вы размещать сервер в облаке или у себя? Не будет ли проблем из-за задержек сигнала между вами и вашим провайдером? Поддерживает ли ваше хранилище такой перенос данных? Если у вас 100 миллионов записей, а за один раз вы можете взять 1000 записей, сколько потребуется на перенос всех данных?
Однако не ставьте масштабируемость превыше всего. Она будет бесполезна, если ваши пользователи решат пользоваться услугами другого сервиса, потому что тот предоставляет больше возможностей и настроек.
Облачные хранилища
Множество поставщиков веб-сервисов предлагают многопользовательские хранилища типа ключ-значение. Большинство из них удовлетворяют критериям, перечисленным выше, однако каждое обладает своими отличительными фичами и отличается от стандартов, описанных выше. Давайте взглянем на конкретные пример хранилищ, такие как SimpleDB, Google AppEngine Datastore и SQL Data Services.Amazon: SimpleDB
SimpleDB - это атрибутно-ориентированное хранилище типа ключ-значение, входящее в состав Amazon WebServices. SimpleDB находится в стадии бета-версии; пользователи могут пользовать ей бесплатно - до тех пор пока их потребности не превысят определенный предел.
У SimpleDB есть несколько ограничений. Первое - время выполнения запроса ограничено 5-ю секундами. Второе - нет никаких типов данных, кроме строк. Все хранится, извлекается и сравнивается как строка, поэтому для того, чтобы сравнить даты, вам нужно будет преобразовать их в формат ISO8601. Третье - максимальные размер любой строки составляет 1024 байта, что ограничивает размер текста (например, описание товара), который вы можете хранить в качестве атрибута. Однако поскольку структура данных гибкая, вы можете обойти это ограничения, добавляя атрибуты «ОписаниеТовара1», «Описание товара2» и т.д. Но количество атрибутов также ограничено - максимум 256 атрибутов. Пока SimpleDB находится в стадии бета-версии, размер домена ограничен 10-ю гигабайтами, а вся база не может занимать больше 1-го терабайта.
Одной из ключевых особенностей SimpleDB является использование модели конечной констистенции (eventual consistency model). Эта модель подходит для многопоточной работы, однако следует иметь в виду, что после того, как вы изменили значение атрибута в какой-то записи, при последующих операциях чтения эти изменения могут быть не видны. Вероятность такого развития событий достаточно низкая, тем не менее, о ней нужно помнить. Вы же не хотите продать последний билет пяти покупателям только потому, что ваши данные были неконсистентны в момент продажи.
Google AppEngine Data Store
Google"s AppEngine Datastore построен на основе BigTable, внутренней системе хранения структурированных данных от Google. AppEngine Datastore не предоставляет прямой доступ к BigTable, но может восприниматься как упрощенный интерфейс взаимодействия с BigTable.
AppEngine Datastore поддерживает большее число типов данных внутри одной записи, нежели SimpleDB. Например, списки, которые могут содержать коллекции внутри записи.
Скорее всего вы будете использовать именно это хранилище данных при разработке с помощью Google AppEngine. Однако в отличии от SimpleDB, вы не сможете использовать AppEngine Datastore (или BigTable) вне веб-сервисов Google.
Microsoft: SQL Data Services
SQL Data Services является частью платформы Microsoft Azure . SQL Data Services является бесплатной, находится в стадии бета-версии и имеет ограничения на размер базы. SQL Data Services представляет собой отдельное приложение - надстройку над множеством SQL серверов, которые и хранят данные. Эти хранилища могут быть реляционными, однако для вас SDS является хранилищем типа ключ-значение, как и описанные выше продукты.
Необлачные хранилища
Существует также ряд хранилищ, которыми вы можете воспользоваться вне облака, установив их у себя. Почти все эти проекты являются молодыми, находятся в стадии альфа- или бета-версии, и имеют открытый код. С открытыми исходниками вы, возможно, будете больше осведомлены о возможных проблемах и ограничениях, нежели в случае использования закрытых продуктов.CouchDB
CouchDB - это свободно распространяемая документо-ориентированная БД с открытым исходным кодом. В качестве формата хранения данных используется JSON. CouchDB призвана заполнить пробел между документо-ориентированными и реляционными базами данных с помощью «представлений». Такие представления содержат данные из документов в виде, схожим с табличным, и позволяют строить индексы и выполнять запросы.В настоящее время CouchDB не является по-настоящему распределенной БД. В ней есть функции репликации, позволяющие синхронизировать данные между серверами, однако это не та распределенность, которая нужна для построения высокомасштабируемого окружения. Однако разработчики CouchDB работают над этим.
Проект Voldemort
Проект Voldemort - это распределенная база данных типа ключ-значение, предназначенная для горизонтального масштабирования на большом количестве серверов. Он родилась в процессе разработки LinkedIn и использовалась для нескольких систем, имеющих высокие требования к масштабируемости. В проекте Voldemort также используется модель конечной консистенции.Mongo
Mongo - это база данных, разрабатываемая в 10gen Гейром Магнуссоном и Дуайтом Меррименом (которого вы можете знать по DoubleClick). Как и CouchDB, Mongo - это документо-ориентированная база данных, хранящая данные в JSON формате. Однако Mongo скорее является объектной базой, нежели чистым хранилищем типа ключ-значение.
Drizzle
Drizzle представляет совсем другой подход к решению проблем, с которыми призваны бороться хранилища типа ключ-значение. Drizzle начинался как одна из веток MySQL 6.0. Позже разработчики удалили ряд функций (включая представления, триггеры, скомпилированные выражения, хранимые процедуры, кэш запросов, ACL, и часть типов данных), с целью создания более простой и быстрой СУБД. Тем не менее, Drizzle все еще можно использовать для хранения реляционных данных. Цель разработчиков - построить полуреляционную платформу, предназначенную для веб-приложений и облачных приложений, работающих на системах с 16-ю и более ядрами.
Решение
В конечном счете, есть четыре причины, по которым вы можете выбрать нереляционное хранилище типа ключ-значение для своего приложения:- Ваши данные сильно документо-ориентированны, и больше подходят для модели данных ключ-значение, чем для реляционной модели.
- Ваша доменная модель сильно объектно-ориентированна, поэтому использования хранилища типа ключ-значение уменьшит размер дополнительного кода для преобразования данных.
- Хранилище данных дешево и легко интегрируется с веб-сервисами вашего вендора.
- Ваша главная проблема - высокая масштабируемость по запросу.
Для всех остальных требований лучше выбрать старые добрые реляционные СУБД. Так обречены ли они? Конечно, нет. По крайней мере, пока.
1 - по моему мнению, здесь больше подходит термин «структура данных», однако оставил оригинальное data model.
2 - скорее всего, автор имел в виду, что по своим возможностям нереляционные БД уступают реляционным.
3 - возможно, данные уже устарели, статья датируется февралем 2009 года.
Уровень 1: Уровень внешних моделей – это самый верхний уровень где каждая модель имеет свое видение данных. Этот уровень определяет точку зрения базы данных отдельных приложений.
Концептуальный уровень: Центральное управляющее звено, где здесь БД представлена в наиболее общем виде, который объединяет данные используемые всеми приложениями. Фактически концептуальный уровень отражает обобщённую модель предметной область.
Физический уровень (База данных): Это сами данные расположенные в файлах или в страничных структурах, расположенных навнешних носителях информации.
Модели данных
Выделяют следующие модели данных:
1. Инфологические
2. Дата логические
3. Физические
Процесс проектирования баз данных начинается с проектирования инфологической модели. Инфологическая модель данных это обобщённое неформальное описание создаваемой БД, выполненное с использованием естественного языка, математических формул, таблиц, графиков и др. средств понятных всем людям работающим над проектированием БД.
Кортеж доменов
Инфологическая модель отображает реальный мир в некоторой понятной человеку концепции, полностью независимой от среды хранения данных. Поэтому Инфологическая модель не должна изменяться до тех пор, пока какие то изменения в реальном мире не потребуют изменения вне определения, чтобы эта модель продолжала отображать предметную область.
Существует множество подходов к построению этой модели: графовые модели, семантические сети, сущность – связь и другие.
Даталогическая модель
Инфологическая модель должна быть отображена в даталогической модели, понятной СУБД. Даталогическая модель это формальное описание инфологической модели на языке СУБД.
Иерархическая модель
Эта модель представляет собой совокупность связанных элементов, образующих иерархическую структуру. К основным понятиям иерархии относятся уровень, узел и связь.
связь уровень
Узлом называется совокупность атрибутов данных описывающих некоторый объект. Каждый узел связан с одним узлом более высокого уровня и с любым количеством узлов нижнего уровня. Исключением является узел самого высокого уровня. Количество деревьев в базе данных определяется количеством корней деревьев. К каждой записи базы данных существует единственный путь от корневой записи. Простым примером может служить система доменных имен в интернете\ адрес. На первом уровне (корень дерева) лежит наша планета земля, на втором Страна, на третьем- Регион, на четвёртом – населённый пункт, улица, дом,квартира. Типичным представителем является СУБД от IBM - IMS.
Все экземпляры данного типа потомка с общим экземпляром типа предка называется близнецами. Для базы данных определён полный порядок обхода. Сверху вниз и с права на лево.
Физическая модель
На основе даталогической модели строится физическая модель. Физическая организация данных оказывает основное влияние на эксплуатационные характеристики базы данных. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий, для под настройки модели для конкретной БД.
Пример: В частности для реляционной БД она уже учитывает:
1. Физические аспекты хранения таблиц в определённых файлах.
2. Создание индексов оптимизирующих скорости операций над данными с помощью приложения.
3. Выполнения различных действий над данными при определённых событиях, определяемых пользователям с помощь триггеров и хранимых процедур.
Инфологические модели ХДля всех уровней и для любого метода представления предметной области, лежит кодирование понятий отношений между понятиями. Ключевым этапом при разработке любой информационной системы является проведение системного анализа:
Формализация предметной области и представление системы как совокупности компонентов.
Композиция как основа системного анализа может быть функциональной (построение иерархия).
Однако в большинстве систем, если говорить о базах данных, типы данных являются более статичным элементом чем способы их обработки. Поэтому получили интенсивное развитие такие методы системного анализа как диаграмма потоков data flown diagram. Развитие реляционных БД. Стимулировала развитие построения методик развития данных в частности ER диаграмм ER. Реляционная модель данных в качестве отображения непосредственно использует понятие отношения. Она ближе всего находится к концептуальной модели представления данных. И часто лежит в основе её.
В отличие от теоретика графовых моделей, в реляционной модели связи между отношениями реализуются не явным способом для чего используют ключи отношений. Например, отношения иерархического типа реализуется механизмом первичных и внешних ключей, когда в подчинённом отношении должен присутствовать факт атрибутов.
Такой атрибут отношений в основном отношений будет называться первичным ключом, а в подчинённом вторичным.
Прогресс в области разработки языков программирования связанных в первую очередь с типизацией данных и появлением объектно-ориентированных языков позволило подойти к анализу сложных систем с точки зрения иерархических представлений то есть с помощью классов объектов со свойствами полиморфизма, наследование, инкапсуляция.
ОТНОШЕНИЕ ЭТО ТАБЛИЦА.
Удаление то что создали и
Редактирование.
Реляционная модель базы данных
Реляционные модели данных в настоящее время приобрели наибольшую популярность именно за такое представление данных.
Реляционную модель можно представить как особый метод представления данных, содержащий собственные данные (в виде таблиц), и способы работы и манипуляции с ними (в виде связей). Реляционная модель предполагает три концептуальных элемента: Структура, Целостность и Обработка данных. В этих элементах есть свои обязательные понятия которые для дальнейшего изложения необходимо пояснить.
Таблица рассматривается как непосредственное хранилище данных. Традиционно в реляционных системах таблицу называют отношением. Строку таблицы называют кортежем , а столбец атрибутом . При этом атрибуты имеют уникальные имена (в пределах отношения).
Количество кортежей в таблице называют кардинальным числом . Количество атрибутов степенью. Для отношения устанавливают уникальный идентификатор, то есть один или несколько атрибутов, значения которых в одно и то же время не бывают одинаковыми – идентификатор называют первичным ключом.Домен это множество допустимых однородных значений для того или иного атрибута. Таким образом домен можно рассмотреть как именованное множество данных причём составные части этого множества являются логически не делимыми единицами (в качестве домена могут выступать например перечень фамилий сотрудников учреждения однако не все фамилии могут присутствовать в таблице).
SUMMОтношение
атрибуты
Поля KOD, NAME, SUMM это атрибуты таблицы содержащиеся в заголовке.
Пары KOD 5216, NAME Киреева, SUMM 25.50 являются элементами тела отношения.
В Реляционных базах данных в отличие от других моделей пользователь указывает какие данные для него необходимы а не то как это делать. По этой причине процесс перемещения и навигации по базе данных в реляционных системах является автоматическим, а эту задачу в СУБД выполняет оптимизатор. Его работа заключается в том чтобы наиболее эффективным способом произвести выборку данных из базы данных по запросу. Таким образом, оптимизатор по крайней мере должен суметь определить из каких таблиц выбираются данные насколько много информации в этих таблицах и каков физический порядок записи в таблицах и как они сгруппированы.
Кроме того реляционная БД выполняет и функции каталога. В каталоге хранится описание всех объектов из которых состоит база данных: таблиц, индексов, триггеров и т.п. Очевидно, что жизненно необходимо для правильной работы всей системы, такой компонент как оптимизатор. Оптимизатор использует информацию хранящуюся в каталоге. Интересен тот факт что каталог сам является набором таблиц, поэтому СУБД может манипулировать им традиционными способами, не прибегая к каким либо особым приёмам и методам.
Домены и отношения
Основные определения: Домены, виды отношений, предикаты.
Отношения имеет ряд основных свойств:
1. В самом общем случае в отношениях не бывает общих кортежей – это следует из самого определения отношений. Однако для некоторых СУБД в ряде случаев допускается отступление от этого свойства. По сколько в отношений имеет место первичный ключ, одинаковые кортежи – исключены.
2. Кортежи не упорядочены сверху вниз – в отношении просто отсутствует понятие позиционного номера. В отношений без потери информации можно с успехом расположить кортежи в любом порядке.
3. Атрибуты не упорядочены слева на право. Атрибуты в заголовке отношений можно располагаетесь в любом порядке, при этом целостность данных не нарушается. Поэтому понятие позиционного номера в отношении атрибута тоже не существует.
4. Значение атрибутов состоят из логически не делимых единиц – это следует из того, что значения берутся из доменов иначе можно сказать, что отношения не содержат групп повторений. То есть являются нормализованными.
В реляционных системах поддерживается несколько видов отношений:
1. Именованные представляют собой переменные отношения определяемые в СУБД путём операторов создания и как правило необходимые для более удобного представления информации для пользователя.
2. Базовые отношения являются непосредственно важной частью БД, поэтому при проектировании им дают собственное название.
3. Производное отношение это то которое было определено через другие, как правило базовые, отношения путём использования средств СУБД.
4. Представление это фактически является именованным производным отношением, при этом представление выражается исключительно через операторы СУБД, применённые к именованным отношениям, поэтому их физически в БД не существует.
5. Результат запросов это не именованное производное отношение содержащее данные(результат конкретного запроса). Результат в БД не хранится а существует до тех пор пока он необходим пользователю.
6. Хранимое отношение это то которое физически поддерживаются в памяти отношений, к хранимым отношениям чаше всего относятся база отношений. Исходя из вышесказанного, можно определить реляционную базу данных как набор отношений, связанных между собой.
Связь в данном случае это ассоциирование двух или более отношений.
| KOD | ADRES |
∞ Бинарная связь
| Студенты |
| Преподы |
| Расписание занятий |
| ∞ |
| ∞ |
| ∞ |
| Студенты |
Тернарные связи
Целостность данных
В реляционных моделях вопросу целостности данных отводят особое место. Напомним, что ключ или потенциальный ключ это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый кортеж, минимальность означает что исключение из набора любого атрибута не позволяет идентифицировать кортеж по оставшимся атрибутам.
Каждое отношение обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ.
При выборе первичного ключа следует отдавать предпочтение не составным ключам или ключам, составленных из минимального набора атрибутов. Нежелательно также использовать ключи с длинными текстовыми значениями (Предпочтительней использовать в качестве ключей целочисленные атрибуты) . Так для идентификации работника можно использовать либо уникальный табельный номер, или номер паспорта, либо набор из фамилий имени отчества и номера отдела. Не допускается что бы первичный ключ отношения, то есть любой атрибут участвующий в первичном ключе принимал неопределённые значения. В этом случае возникнет противоречивая ситуация (коллизия ): Появится не обладающий уникальностью элемент первичного ключа. Поэтому при проектировании базы данных за этим следует тщательно следить.
О внешних ключах. Стоит отметить ввиду что отношение С связывает отношения B и А, то оно должно включать внешние ключи, соответствующий первичным ключам отношениям А и В.
Внешний ключ таблицы формируется с помощью нескольких первичных ключей других таблиц.
Таким образом при рассмотрении проблемы выбора способа связи отношения в базе данных возникает вопрос о том каковы же должны быть внешние ключи. При этом для каждого внешнего ключа необходимо решить проблему связанную с возможностью (или невозможностью) появления во внешних ключах неопределённых значений(NULL – значений- значение атрибута для отсутствующей информации). Другими словами может ли существовать некоторый кортеж в отношений, для которого не известен кортеж в связанных с ним отношении?
С другой стороны необходимо заранее обдумать вопрос о том что произойдёт при удаления кортежей из отношения на который ссылается внешний ключ. При этом существуют следующие вероятные возможности:
· Операция каскадируется – то есть удаление кортежей в отношениях приводит к удалению кортежей связанных отношением. Например удаление информации о фамилии имени и т.п. сотрудника в одном отношении приводит к удалению о его заработной плате в другом отношении;
· Операция ограничивается - то есть удаляются лишь те кортежи для которых связанной информации в другом отношении нет. Не вся информация удаляется (не во всех отношениях) так как она может быть использована в другом отношении, удаление информации в котором ведёт к нарушению целостности данных. Если такова информация имеется то удаление осуществить нельзя, например, удаление информации о имени, фамилии и т.п. сотрудника возможно лишь в том случае если информация в связанном отношении о его заработной плате отсутствует.
Нужно предусмотреть технологию того что будет происходить при попытке обновления первичного ключа отношения, на которые ссылается некоторый внешний ключ. Здесь имеются те же возможности как и при удалении:
· Операция каскадируется то есть при обновлении первичного ключа происходит обновление внешнего ключа в связанном отношении. Например обновление первичного ключа в отношении, где хранится информация о сотруднике приводит к обновлению внешнего ключа в отношении с информацией о заработной плате.
· Операция ограничивается то есть обновляются лишь те первичные ключи для которых связанной информации в другом отношении нет. Если таковая информация имеется то обновление сделать нельзя. Например обновление первичного ключа в отношении, где хранится информация о сотруднике, возможна лишь в том случае, если информация о его заработной плате в связанном отношении отсутсвует.1
Реляционная алгебра
Формальной основой базы реляционной модели БД является реляционная алгебра, основанное на теории множеств и рассматривающая специальный оператор над отношениями, и реляционное исчисление базирующиеся на математической логике.
| Произведение |
| А А А Б В В | Г Г Д |
| Г Д |
| А |
| А Б В | Г Г Д | Ж Ж З |
Надо отметить что реляционная алгебра обладает большой мощностью - сложные запросы к базе данных могут быть выражены с помощью одного выражения. Именно по этой причине эти механизмы включены в реляционную модель данных. Любой запрос выражаемый с помощью одного выражения реляционной алгебры, или одной формулой реляционного исчисления, может быть выражен с помощью одного оператора этого языка.
Реляционная алгебра обладает важным свойством - она замкнута относительно понятия отношения. Это означает что выражение реляционной алгебры выполняется над отношениями реляционных баз данных и результаты их вычисления также представляют собой отношения.
Основная идея реляционной алгебры состоит в том что средства манипулирования отношениями, рассматриваемыми как множество основаны на традиционных множественных операциях дополненных некоторыми специфическими операциями для БД.
Опишем вариант алгебры который был предложен КОДДОМ. Операция состоит из 8 основных операторов:
· Выборка отношения (унарная операция)
· Проекция отношения (унарная операция)
· Объединения отношений
· Пересечение отношений(бинарная операция)
· Вычитание отношений
· Произведение отношений
· Соединение отношений
· Деление отношений
Эти операции можно объяснить следующим образом:
· Результатом выборки отношения по некоторому условию является отношение который включает только те кортежи первоначального отношения которые удовлетворяют этому условию.
· При осуществлении проекции отношения на заданный набор его атрибутов будет получено отношение кортежи которого взяты из соответствующих кортежей первого отношения.
· При выполнении операции объединения двух отношений будет получено отношение включающее все кортежи входящие в хотя бы одно из участвующих в операции отношений.
· При выполнении операции пересечения двух отношений будет получено отношение включающее все кортежи входящие в оба первоначальных отношения.
· При выполнении операции вычитания двух отношений будет получено отношение включающее все кортежи входящие в первое отношение, кроме тех которые также входят и во второе отношение.
· При выполнении прямого произведения двух отношений получается отношение кортежи которого являются сочетанием кортежей первого и второго отношения.
· При соединении двух отношений по некоторому условию образуется результирующее отношение кортежей которого является сочетанием кортежей первого и второго отношений, удовлетворяющим этому условию.
· Операция реляционного деления имеет два операнда – бинарная то есть (состоящее из двух атрибутов) и унарная (состоящая из одного атрибута) отношения. Результат операции является отношение состоящее из кортежей включающие отношение первого атрибута кортежей первого отношения, причем таких что множество значений второго атрибута совпадает со множеством значений второго отношения.
Помимо выше перечисленных есть ряд особых операций характерных для работы с базами данных:
· В результате операции переименования получается отношение набор кортежей, которого совпадает с телом первоначального отношения, но имена атрибутов изменены.
Отсюда следует что результатом реляционной операции является некоторое отношение то имеется возможность образовывать реляционные выражения в которых вместо первоначального отношения (операнда), будет использоваться вложенное реляционное выражение. Это происходит благодаря тому факту что операция реляционной алгебры действительно замкнуты относительно понятия отношения. Начнём с операции объединения отношений , однако это в равной мере относится и к операциям пересечения и сочетания, то есть в реляционной алгебры результатом операции объединения является отношение. Если допустить в реляционной алгебре возможность объединения произвольных двух отношений с разными наборами атрибутов, то результатом такой операции будет множество, однако множество разнотипных кортежей, то есть вообще говоря не отношение. Если исходить из требования замкнутости реляционной алгебры относительно понятия отношения то такая операция объединения является бессмысленной. Это приводит к появлению понятия совместимости отношений по объединению : два отношения совместимы только в том случае, когда обладают одинаковыми заголовками, то есть имеет тот же набор имён атрибутов, и одноимённые атрибуты определены в том же домене.
При условии что два отношения совместимы по объединению, при обычном выполнении над ними операции объединения пересечения вычитания результатом операции является отношение с корректно определённым заголовком совпадающим с заголовком каждого из отношений – операндов. Если же два отношения не полностью совместимы по объединению, то есть совместимы во всем кроме имён атрибутов, то до выполнения операции типа соединения, эти отношения можно сделать полностью совместимыми по объединению путём применения операции переименования.
Операция прямого произведения двух отношений вызывает новые проблемы. В Теории множеств прямое произведение может быть получено для любых множеств. Элементы результирующего множества будут являться пары, составленные из элементов первого и второго множества. Поскольку отношения являются множествами то для любых двух отношений возможно получение прямого произведения. Однако результат не будет отношением. Элементами результата будут являться не кортежи, а пары кортежей. Поэтому в реляционной алгебре используется специальная форма операции взятия прямого произведения - расширенное прямое произведение отношений. При взятии расширенного прямого произведения двух отношений элементом результирующего отношения является кортеж, формирующийся при слиянии одного кортежа первого отношения, и одного кортежа второго отношения. Тут же возникает вторая проблема, связанная с получением корректно сформированного заголовка результирующего отношения, это приводит к необходимости ввода понятия совместимости отношений, по взятию расширенного прямого произведения.
Два отношения совместимы по взятию прямого произведения только в том случае, если множество имен атрибутов этих отношений не пересекаются. Любые два отношения могут быть преобразованы к совместимому виду по взятию прямого произведения путём применения операции переименования к одному из этих отношений.
Операция выборки требует наличия двух отношений: первоначального отношения – операнда, и простого условия ограничения. В результате выполнения операции выборки производится отношение заголовок которого совпадает с заголовком отношения операнда, а в тело входят те кортежи отношения операнда, которые удовлетворяют значениям условия ограничения.
Введём ряд операторов.
Пусть union означает операцию объединения, intersect – операция пересечение, minus – операция вычитания. Для обозначения операции выборки будем использовать конструкцию A where B , где А – отношение операнд, а В простое условие сравнения. Пусть С1 и С2 два простых условия выборки
A where C1 AND C2 идентично (A where C1) intersect (A where C2)
A where C1 OR C2 идентично (A where C1) union (A where C2)
A where C1 not C2 идентично (A where C1) minus (A where C2)
С использованием этих определений можно реализовать операции выборки, в которых условием выборки является произвольное логическое выражение составленное из простых условий с использованием логических связей (and, or, not) . Операция взятия проекций отношение А оп списку атрибутов а1, а2,…,an будет отношение заголовком которого является множество атрибутов, а1,а2,…,an. Тело результата будет состоять из кортежей для которых в отношении А имеется кортеж, атрибут а1 имеет значение b1, атрибут а2 значение b2< и так далее атрибут an – bn. По сути при выполнении операции проекции определяется «Вертикальная» вырезка отношения - операнда с удалением возникающих кортежей –дубликатов.
Операция соединения, называемая иногда соединением по условию требует наличия двух операндов – соединяемых отношений, и третьего операнда – простое условие. Пусть соединяется отношение А и В. Как и в случае операции выборки, условие соединения С имеет вид, (а comp –op b) либо (а comp –op const) где А и В имена атрибутов отношений А и В, const- литерально заданная константа. Comp-op – допустимая в данном контексте операция сравнения. Тогда по определению результатом операции соединения является отношение, получаемое путём, выполнения операции ограничения, по условию С прямого произведения отношения А и В.
Имеется важный частный случай соединения, естественное соединение. Операция соединения называется операцией естественного соединения, если условия соединения имеет вид (а=в) где а и в атрибуты разных операндов соединения. Этот случай важен потому что он особо часто встречается на практике и для него существуют эффективные алгоритмы реализации в СУБД. Операция естественного соединения применяется к паре отношений А и В, обладающих общим атрибутом Р, то есть атрибутом с одним и тем же именем и определённым на одном и том же домене. Пусть ав обозначает объединение заголовков отношений А и В. Тогда естественное соединение это спроецированный на ав результат соединения А и В. Операции естественного соединения не включается прямо в состав набора операций реляционной алгебры, но она имеет очень важное практическое значение.
Операция деления отношений нуждается в более подробном объяснении поскольку трудна для понимания. Пусть заданы два отношение А {a1,a2,..,an,b1,b2,…,bm}
B {b1,b2,…,bn} Будем полагать что атрибут b1 отношения A и атрибут b1 отношения B определены на одном и том же домене. Назавём множество атрибутов {aj} составным атрибутом а, множество {bj} cсоставным атрибутом b. После этого будем говорить о реляционном делении бинарного отношения А (а,b) на унарное отношение B (b).
Результатом деления А на В является унарное отношение С (а), состоящее из таких кортежей v что в отношении А имеются кортежи
Поскольку деление наиболее трудная операция поясним её примером. Пусть в БД студентов имеется два отношения: СТУДЕНТЫ (ФИО, НОМЕР) и ИМЕНА (ФИО), причем унарное отношение ИМЕНА содержит все фамилии которыми обладают студенты института. Тогда после выполнения операции реляционного деления отношения СТУДЕНТЫ на отношения ИМЕНА, будет получено унарное отношение содержащее номера студенческих билетов принадлежащих студентам со всеми возможными в этом институте фамилиями.
Реляционное счисление
Допустим имеется база данных обладающая структурой СТУДЕНТЫ (номер, имя, стипендия, код группы), и отношение ГРУППЫ(гр_ном, гр_кол, гр стар) Предположим что необходимо узнать имена и номера студ. билетов у студентов являющимися старостами групп с количеством человек больше 25. В реляционной алгебре нужно предпринять следующие действия для такого запроса:
1. Выполнить соединение отношений СТУДЕНТЫ и ГРУППЫ, по условию «студ_ номер =гр_стар»;
2. Ограничить полученное отношение по условию гр_кол>25.
3. Cпроецировать результат предыдущей операции на атрибут студ_имя, студ_номер.
Здесь пошагово сформулирована последовательность выполнения запроса в базе данных, каждый из которых соответствует одной реляционной операции. если же сформулировать тот же запрос с использование реляционного исчисления То мы получили бы формулу которую можно прочитать: Выдать СТУД_ИМЯ и СТУД_НОМЕР для таких студентов чтобы сосуществовала такая группа ГР_СТАР и значением ГР_КОЛ>25. Во второй формулировке мы указали лишь характеристики результирующего отношения но ничего не сказали о способе его формирования. В этом случае СУБД должна сама решить что за операции и в каком порядке нужно выполнить над отношениями СТУДЕНТЫ и ГРУППЫ. Оба рассмотренных в примере способа на самом деле эквиваленты и существует не очень сложные преобразования из одного в другой.
Базисными понятиями реляционного счисления являются понятия переменной с определённой область её значения, и понятия правильно построенной формулы, опирающиеся на переменные и спец. Функции. Что является областью определения переменной различаются исчисление кортежей, и исчисления доменов то есть вдоль или поперёк. В исчислении кортежей областями определения переменных является отношение баз данных, то есть допустимым значением каждой переменной является кортеж некоторого отношения. В исчислении доменов областями определения переменных являются домены на которых определены атрибуты отношений баз данных то есть допустимым значением каждой переменной является значение каждой переменной.
| Byte | Integer | String | Char | |
| M | ||||
| | N | |||
| K | ||||
Для определения кортежи используется команда RANGE. Например чтобы определить переменную СТУДЕНТ областью определения которой является СТУДЕНТЫ нужно употребить конструкцию RANGE СТУДЕНТ IS СТУДЕНТЫ. Из этого определения следует что в любой момент времени переменная студент представляет некоторый кортеж отношения СТУДЕНТЫ. При использовании кортежных переменных в формулах можно ссылать на значения атрибута переменных. Например для того чтобы сослаться на значение атрибута СТУД_ИМЯ переменной СТУДЕНТ нужно употребить конструкцию СТУДЕНТ.СТУД_ИМЯ.
Правильно построенные формулы служат для выражения условий, накладываемых на кортежные переменные. В основе таких формул лежат простые сравнения, представляющие собой, операции сравнения значений атрибутов переменных и литерально заданных констант. Например конструкция СТУДЕНТ.СТУД_НОМ=123456. Является простым сравнением. Более сложным вариантом составных формул является с помощью логических связей AND, OR, NOT, IF…THEN. Наконец допускается построение правильно построенных формул с помощью кванторов. Если F это правильно построенная формула в которой участвует переменная var то конструкция EXIST (квантор существования) var (F) и FORALL(для всех кортежей) var (F) являются правильными.
Переменные, входящие в правильно построенные формулы могут быть свободными или связанными. Все переменные входящие в их состав при построение которых не использовались кванторы являются свободными. Это означает что если для какого то набора значений свободных кортежных переменных при вычислении формул получено значение «истина», то эти значения могут входить в результирующие отношение. Если же при построении формул используется квантор то переменные являются связанными. При вычислении значения такой правильно построенной формулы используется ни одно значение связанной переменной а вся её область определения.
1)EXISTS СТУД2 (CТУД.1СТУД_СТИП> СТУД2.СТУД_СТИП)
2)FORALL СТУД2 (CТУД.1СТУД_СТИП> СТУД2.СТУД_СТИП)
Пусть СТУД1 и СТУД2 две кортежные переменные определённые на отношение студенты, тогда формула, для текущего кортежа переменной СТУД1 принимает значение истина только в том случае если во всём отношении студенты найдётся такой кортеж связанный с переменной СТУД2 что значение его атрибута СТУД_СТИП удовлетворяет внутреннему условию сравнения. Правильно построенная формула №2 для построенного кортежа СТУД 1 принимает значение истина если для всех кортежей отношение СТУДЕНТЫ связанных с переменной СТУД 2 значение атрибута СТУД.СТИП удовлетворяет внутреннему условию.
Таким образом правильно построенные формулы обеспечивают средства выражения условия выборки из отношения баз данных. Чтобы можно было использовать реляционное исчисление для реальной работы с БД, требуется ещё один компонент который определяет набор и имена столбцов результирующего отношения. Этот компонент называется целевым списком.
Целевой список имеет вид:
· Var.attr –имя свободной переменной, атр имя атрибута отношения на котором определена переменная var.
· Var что эквивалентно отношению от списка, Var.attr1, Var.attr1… Var.attr№ включает имена всех атрибутов определяющего отношения.
· New_name = var.attr; новое имя соответствующего атрибута результирующего отношения.
Последний вариант требуется в тех случаях кода в формуле используется несколько свободных переменных с одинаковой областью определения. В исчислении доменов областью определения доменов являются не отношения а домены. Применительно к бд СТУДЕНТЫ ГРУППЫ можно говорить о доменных переменных ИМЯ (Значения домена – допустимые имена или НОМ СТУД). (Значения домена допустимые номера студентов).
Основным отличием исчисления доменов от исчисления кортежей является наличие дополнительного набора предикатов, позволяющих выражать так называемые условия членства. Если R это n- арное отношение с атрибутами (a1, a2, … an) то условие членства имеет вид R(ai1:Vi1,ai2:Vi2,…aim:Vim) где (m<=n). Где в Vij это либо литерально заданная константа либо имя кортежной переменной. Условие членства принимает значение истина, только в том случае если в отношении R существует кортеж, содержащий следующие значения указанных атрибутов. Если от Vij константа то на атрибут aij накладывается жёсткое условие независящее от текущих доменных переменных. Если же Vij имя доменной переменной то условие членства может принимать различные значения при разных значениях этой переменной.
Предикатом называют логическую функцию, которая для некоторого аргумента возвращает значение истина или ложь. Отношение может быть рассмотрено как предикат с аргументами, являющимися атрибутами рассматриваемого отношения. Если заданный конкретный набор кортежей присутствует в отношении, то предикат выдаст истинный результат в противном случае – ложный.
Вов всех остальных отношениях формулы и выражения исчисление доменов выглядит похожими на формулы и выражения исчисления кортежей. Реляционное счисление доменов положено в основу большинства языковых запросов, основанных на использовании форм.
Похожая информация.
Реляционные базы данных позволяют хранить информацию в нескольких «плоских» (двухмерных) таблицах, связанных между собой посредством совместно используемых полей данных, называемых ключами. Реляционные базы данных предоставляют более простой доступ к оперативно составляемым отчетам (обычно через SQL) и обеспечивают повышенную надежность и целостность данных благодаря отсутствию избыточной информации
Всем известно, что представляет собой простая база данных: телефонные справочники, каталоги товаров и словари - все это базы данных. Они могут быть структурированными или организованными каким-то иным образом: как плоские файлы, как иерархические или сетевые структуры или как реляционные таблицы. Чаще всего в организациях для хранения информации используются именно реляционные базы данных.
База данных - это набор таблиц, состоящих из столбцов и строк, аналогично электронной таблице. Каждая строка содержит одну запись; каждый столбец содержит все экземпляры конкретного фрагмента данных всех строк. Например, обычный телефонный справочник состоит из столбцов, содержащих телефонные номера, имена абонентов и адреса абонентов. Каждая строка содержит номер, имя и адрес. Эта простая форма называется плоским файлом в силу его двухмерной природы, а также того, что все данные хранятся в одном файле.
В идеале каждая база данных имеет по крайней мере один столбец с уникальным идентификатором, или ключом. Рассмотрим телефонную книгу. В ней может быть несколько записей с абонентом Джон Смит, но ни один из телефонных номеров не повторяется. Телефонный номер и служит ключом.
На самом деле все не так просто. Два или несколько человек, использующих один и тот же телефонный номер, могут быть перечислены в телефонном справочнике по отдельности, в силу чего телефонный номер появляется в двух или более местах, поэтому существует несколько строк с ключами, которые не являются уникальными.
Данные создают проблемы
В самых простых базах данных каждая запись занимает одну строку, иными словами, телефонной компании необходимо заводить отдельный столбец для каждого фрагмента бухгалтерской информации. То есть одну - для второго абонента «спаренного» телефона, еще одну - для третьего и т. д., в зависимости от того, сколько дополнительных абонентов понадобится.
Это значит, что каждая запись в базе данных должна иметь все эти дополнительные колонки, даже если больше они нигде не используются. Это также означает, что база данных должна быть реорганизована всякий раз, когда компания предлагает новую услугу. Вводится обслуживание тонального набора - и меняется структура базы, поскольку добавляется новая колонка. Вводится поддержка идентификации номера звонящего абонента, ожидания звонка и т. д. - и база данных перестраивается снова и снова.
В 60-е годы только самые крупные компании могли позволить себе приобретать компьютеры для управления своими данными. Более того, базы данных, построенные на статических моделях данных и с помощью процедурных языков программирования, таких как Кобол, могут оказаться слишком дорогими в том, что касается поддержки, и не всегда надежными. Процедурные языки определяют последовательность событий, через которую компьютер должен пройти, чтобы выполнить задачу. Программирование таких последовательностей было сложным делом, особенно если требовалось менять структуру базы данных или составлять новый вид отчетов.
Мощные связи
Эдгар Кодд, сотрудник исследовательской лаборатории корпорации IBM в Сан-Хосе, по существу, создал и описал концепцию реляционных баз данных в своей основополагающей работе «Реляционная модель для крупных, совместно используемых банков данных» (A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, июнь 1970).
Кодд предложил модель, которая позволяет разработчикам разделять свои базы данных на отдельные, но взаимосвязанные таблицы, что увеличивает производительность, но при этом внешнее представление остается тем же, что и у исходной базы данных. С тех пор Кодд считается отцом-основателем отрасли реляционных баз данных.
Эта модель работает следующим образом. Телефонная компания может создать основную таблицу, используя в качестве первичного ключа номер телефона, и хранить его с другой базовой информацией о потребителях. Компания может определить отдельную таблицу со столбцами для этого первичного ключа и для дополнительных служб, таких как поддержка идентификации номера звонящего абонента и ожидание звонка. Она также может создать еще одну таблицу для контроля счетов за переговоры, где каждая запись состоит из номера телефона и данных об оплате звонков.
Конечные пользователи могут легко получить ту информацию, которую они хотят, и в том виде, в каком она им требуется, хотя эти данные хранятся в различных таблицах. Поэтому представитель службы поддержки потребителей телефонной компании может отобразить на одном и том же экране информацию о счетах абонента, а также о состоянии специальных служб или о том, когда была получена последняя оплата.
Кодд сформулировал 12 правил для реляционных баз данных, большинство которых касаются целостности и обновления данных, а также доступа к ним. Первые два достаточно понятны даже пользователям, не обладающим техническими навыками.
Правило 1, информационное правило, указывает, что вся информация в реляционной базе данных представляется как набор значений, хранящихся в таблицах.
Правило 2, правило гарантии доступа, определяет, что доступ к каждому элементу данных в реляционной базе данных можно получить с помощью имени таблицы, первичного ключа и названия столбца. Другими словами, все данные хранятся в таблицах, и, если известно название таблицы, первичный ключ и столбец, где находится требуемый элемент данных, его всегда можно извлечь.
Суть работы Кодда заключалась в том, что предлагалось с реляционными базами данных использовать декларативные, а не процедурные языки программирования. Декларативные языки, такие как язык запросов SQL (Structured Query Language), дают пользователям возможность, по существу, сообщить компьютеру: «Я хочу получить следующие биты данных из всех записей, которые удовлетворяют определенному набору критериев». Компьютер сам «поймет», какие необходимо совершить шаги, чтобы получить эту информацию из базы данных.
Для работы с огромным количеством активно используемых баз данных применяются программные системы управления реляционными базами данных, созданные такими авторитетными производителями, как Oracle, Sybase, IBM, Informix и Microsoft.
Хотя большую часть вариантов реализаций SQL можно назвать интероперабельными лишь с известным приближением, этот утвержденный в качестве международного стандарта механизм позволяет создавать сложные системы, основу которых составляют базы данных. Удобный для программирования интерфейс между Web-сайтами и реляционными базами данных дает конечным пользователям возможность добавлять новые записи и обновлять существующие, а также создавать отчеты для самых разных служб, таких как выполнение интерактивных торговых операций и доступ к интерактивным библиотечным каталогам.
Реляционная модель
Реляционная база данных использует набор таблиц, связанных друг с другом посредством определенного ключа (в данном случае это поле PhoneNumber)
Реляционная модель
Реляционная модель базы данных была предложена в 1969 г. математиком и научным сотрудником фирмы IBM Э.Ф. Коддом (E.F. Codd). Некоторые начальные сведения о реляционных базах данных содержатся в обзорной статье “БД и СУБД ” 2. Поскольку в настоящее время именно реляционные базы данных являются доминирующими, в этой статье (а также в статьях “Описание данных ”, “Обработка данных ” и “Проектирование БД ” 2) подробно рассматриваются наиболее существенные понятия реляционной модели.
Сразу отметим, что теория реляционных баз данных изначально была сформулирована на строгом математическом языке, и именно строгие, формально определенные математические понятия наилучшим образом описывают суть вещей. Вместе с тем в большинстве случаев можно без особого ущерба пожертвовать строгостью терминологии в пользу прозрачности изложения, что мы и будем стараться делать.
Основная идея реляционной модели заключается в следующем. База данных состоит из ряда неупорядоченных таблиц (в простейшем случае - из одной таблицы). Таблицами можно манипулировать посредством непроцедурных (декларативных) операций - запросов , результатами которых также являются таблицы.
Нередко слово “реляционная” (relational ) в термине “реляционная модель” трактуют, основываясь на том, что в реляционной базе данных устанавливаются связи (relate ) между таблицами. Такое объяснение удобно, но оно не является точным. В оригинальной системе терминов Кодда термины связи (relations ), атрибуты (attributes ) и кортежи (tuples ) употреблялись там, где большинство из нас пользуется более привычными терминами таблицы, столбцы (поля) и строки (записи).
При построении инфологической модели предметной области (см. “БД и СУБД ”, “Проектирование БД ” 2) выделяются сущности (объекты), описываются их свойств а (характеристики, атрибуты), существенные для целей моделирования, и устанавливаются связи между сущностями. На этапе перехода от инфологической к даталогической реляционной модели как раз и появляются таблицы. Как правило, каждая сущность представляется одной таблицей. Каждая строка таблицы (одна запись) соответствует одному экземпляру сущности, а каждое поле описывает некоторое свойство (атрибут) .
Например, если нам требуется хранить информацию о людях, включающую фамилию каждого, имя, отчество, ИНН, страну проживания и дату рождения, то сущностью является именно человек, а указанные данные - атрибутами. Сама сущность естественным образом становится названием таблицы.
Таблица “Человек”
Реляционная модель требует, чтобы каждая строка таблицы была уникальной, т.е. чтобы любые две строки различались значением хотя бы одного атрибута.
Традиционная табличная форма удобна, когда требуется представить сами данные. Если же, как в приведенном выше примере, интересует лишь структура - имена полей, то с точки зрения наглядности, удобства использования в схемах и экономии места удобнее изображать ее следующим образом:
Ключи
Ключом таблицы называется поле или группа полей, содержащие уникальные в рамках данной таблицы значения . Ключ однозначно определяет соответствующую строку таблицы. Если ключ состоит из одного поля, его часто называют простым , если из нескольких - составным . В приведенном выше примере ключом является поле ИНН (мы считаем известным тот факт, что ИНН в пределах страны являются уникальными).
Рассмотрим пример таблицы с составным ключом. На сайтах прогнозов погоды нередко представляют информацию следующим образом: для каждой даты указывают прогнозируемую температуру ночью, утром, днем и вечером. Для хранения указанной информации можно использовать таблицу следующего вида:
В этой таблице ни поле Дата, ни Время суток, ни Температура не являются ключами - в каждом из этих полей значения могут повторяться. Зато комбинация полей Дата+Время суток является уникальной и однозначно определяет строку таблицы. Это и есть составной ключ.
Нередко встречается ситуация, в которой выбор ключа не является однозначным. Вернемся к первому примеру. Допустим, в дополнение к фамилии, имени, отчеству, ИНН, дате рождения требуется хранить серию и номер общегражданского паспорта и серию и номер заграничного паспорта. Таблица будет иметь следующий вид.
В этой таблице можно выбрать целых три ключа. Один из них - простой (ИНН), два другие - составные (Серия+Номер общегражданского паспорта и Серия+Номер заграничного паспорта). В такой ситуации разработчик выбирает наиболее удобный с точки зрения организации БД ключ (в общем случае - ключ, на поиск значения которого требуется наименьшее время). Выбранный ключ в этом случае часто называют главным, или первичным , ключом, а другие комбинации столбцов, из которых можно сделать ключ, - возможными , или альтернативными, ключами. Отметим, что хотя бы один возможный ключ в таблице имеется всегда, так как строки не могут повторяться и, следовательно, комбинация всех столбцов гарантированно является возможным ключом.
При изображении таблиц первичные ключи таблиц принято выделять. Например, соответствующие поля часто подчеркивают. А Microsoft Access выделяет ключевые поля полужирным шрифтом.
Еще чаще, чем с неоднозначностью выбора ключа, разработчики сталкиваются с отсутствием ключа среди данных, которые требуется хранить. Подобный факт может быть установлен в процессе анализа предметной области. Например, если требуется хранить простой список людей - имена, фамилии, отчества и даты рождения, то ключа в этом наборе атрибутов нет вовсе - мыслимой является ситуация, когда у двух различных людей указанные данные совпадают полностью. В таком случае приходится искусственно вводить дополнительное поле, например, уникальный номер человека. Такой ключ в литературе иногда называют суррогатным . Нередко суррогатный ключ вводят и из соображений эффективности. Если, например, в таблице имеется длинный составной ключ, то разработчики часто вводят дополнительный короткий числовой суррогатный ключ и именно его делают первичным. Нередко так поступают даже при наличии простого ключа, имеющего “неудобный” (неэффективный для поиска) тип данных, например, строковый. Подобные операции уже не имеют отношения к теории, но сплошь и рядом встречаются на практике.
Внимательный читатель, возможно, обратит внимание на то, что ключ практически всегда можно расширить (если только в него не входят все поля таблицы) за счет включения избыточных полей. Формально такой ключ останется ключом, но с практической точки зрения это лишь игра понятиями. Такие ключи и за возможные-то не считают, поскольку всегда необходимо стремиться к минимизации длины (сложности) ключа.
Нормальные формы, нормализация
Не всякая таблица, которую мы можем нарисовать на бумаге или в Word’е, может быть таблицей реляционной базы данных. И не всякая таблица, которая может использоваться в реляционной базе данных, является правильной с точки зрения требования реляционной модели.
Во-первых, требуется, чтобы все данные в пределах одного столбца имели один и тот же тип (о типах см. “Описание данных ” 2). С этой точки зрения приведенный ниже пример не имеет смысла даже обсуждать:
Во-вторых, требуется, чтобы в таблице был назначен первичный ключ .
Указанные требования являются необходимыми, но недостаточными. В теории реляционных баз данных вводятся понятия так называемых “нормальных форм” - требований к организации данных в таблицах. Нормальные формы нумеруются последовательно, по мере ужесточения требований. В правильно спроектированной БД таблицы находятся как минимум в третьей нормальной форме. Соответственно, мы рассмотрим первые три нормальные формы. Напомним, что мы имеем дело с таблицами, удовлетворяющими двум сформулированным выше основным требованиям.
Первая нормальная форма (1НФ)
Первая нормальная форма предписывает, что все данные, содержащиеся в таблице, должны быть атомарными (неделимыми ). Перечень соответствующих атомарных типов данных определяется СУБД. Требование 1НФ совершенно естественное. Оно означает, что в каждом поле каждой записи должна находиться только одна величина, но не массив и не какая-либо другая структура данных. Приведем осмысленный пример таблицы, которая не находится в 1НФ. Пусть у нас имеются списки оценок учеников по некоторому предмету.
Так как значение поля Оценки не является атомарным, таблица не соответствует требованиям 1НФ.
О возможном способе представления списка оценок написано в методических рекомендациях к статье “Проектирование БД” 2.
Вторая нормальная форма (2НФ)
Говорят, что таблица находится во второй нормальной форме, если она находится в 1НФ и каждый не ключевой столбец полностью зависит от первичного ключа. Другими словами, значение каждого поля должно полностью определяться значением первичного ключа. Важно отметить, что зависимость от первичного ключа понимается именно как зависимость от ключа целиком, а не от отдельной его составляющей (в случае составного ключа). Приведем пример таблицы, которая не находится во 2НФ. Для этого вернемся к примеру прогноза погоды и дополним таблицу еще одним столбцом - временем восхода солнца (это вполне правдоподобный пример, такого рода информация часто приводится на сайтах прогноза погоды).
Как мы помним, данная таблица имеет составной ключ Дата+Время суток. Поле Температура полностью зависит от первичного ключа - с ним проблем нет. А вот поле Восход зависит лишь от поля Дата, Время суток на время восхода естественным образом не влияет.
Здесь уместно задаться вопросом: а в чем практический смысл 2НФ? Какая польза от этих ограничений? Оказывается - большая. Допустим, что в приведенном выше примере разработчик проигнорирует требования 2НФ. Во-первых, скорее всего возникнет так называемая избыточность - хранение лишних данных. Ведь если для одной записи с данной датой уже хранится время восхода, то для всех других записей с данной датой оно должно быть таким же и хранить его, вообще говоря, незачем.
Обратим внимание на слова “должно быть”. А если не будет? Ведь на уровне БД это никак не контролируется - ключ в таблице составной, одинаковые даты могут быть (и по смыслу скорее всего будут). И никакие формальные ограничения (а наше понимание, что “такого не может быть”, к таковым не относится) не запрещают указать разное время восхода для одной и той же даты.
Третья нормальная форма (3НФ)
Говорят, что таблица находится в 3НФ, если она соответствует 2НФ и все не ключевые столбцы взаимно независимы.
Взаимную зависимость столбцов удобно понимать следующим образом: столбцы являются взаимно зависимыми, если нельзя изменить один из них, не изменяя другой.
Приведем пример таблицы, которая не находится в 3НФ. Рассмотрим пример простой записной книжки для хранения домашних телефонов людей, проживающих, возможно, в различных регионах страны.
В этой таблице присутствует зависимость между не ключевыми столбцами Город и Код города, следовательно, таблица не находится в 3НФ.
Отметим, что наличие указанной выше зависимости разработчик определяет, анализируя предметную область, - никакими формальными методами подобную коллизию увидеть нельзя. При изменении свойств предметной области зависимость между столбцами может и исчезнуть. Например, если в пределах одного города вводятся различные коды (как 495 и 499 в Москве), соответствующие столбцы перестают быть связанными с точки зрения нарушения требований 3НФ.
В теории реляционных баз данных рассматриваются и формы высших порядков - нормальная форма Бойса - Кодда, 4НФ, 5НФ и даже выше. Большого практического значения эти формы не имеют, и разработчики, как правило, всегда останавливаются на 3НФ.
Нормализация БД
Нормализация представляет собой процесс приведения таблиц базы данных к выбранной нормальной форме. Нормализация до 2НФ, как правило, сводится к декомпозиции - разбиению одной таблицы на несколько. Нормализация до 3НФ обычно может быть выполнена удалением зависимых (вычисляемых) столбцов. В некоторых случаях при нормализации до 3НФ приходится также производить декомпозицию.
Многотабличные БД, связи между таблицами, внешние ключи
На практике однотабличные базы данных встречаются достаточно редко, поскольку с точки зрения моделирования базой данных предметной области наличие одной таблицы означает наличие одной сущности. В свою очередь, наличие нескольких сущностей обычно означает наличие связей между ними.
Не ставя целью полное проектирование БД, рассмотрим пример, позволяющий продемонстрировать связи в многотабличных БД.
Пусть мы имеем дело со школой, в которой есть ученики, сгруппированные по классам, и учителя, преподающие некоторые предметы. У нас сразу выделяются четыре сущности: ученики, учителя, классы и предметы. Эти сущности уже дают нам четыре таблицы.
Далее нам требуется решить вопрос об атрибутах сущностей - какую именно информацию мы будем хранить. Поскольку наш пример носит исключительно демонстрационный характер, постараемся минимизировать объем хранимой информации. Договоримся для каждого ученика хранить фамилию и имя, для класса - номер параллели и букву, идентифицирующую класс внутри параллели, для учителя - фамилию, имя и отчество, для предмета - только его название.
Теперь нам следует решить вопрос с первичными ключами. Таблицы учеников и учителей в принципе не имеют ключа, поэтому мы введем в них суррогатный числовой ключ - номер. Таблицы классов и предметов, вообще говоря, имеют ключи. В таблице классов ключ составной, его образуют атрибуты Номер параллели+Буква, а в таблице предметов простой ключ состоит из единственного поля - названия предмета. Вспомним, что, говоря о ключах, мы упоминали о том, что суррогатные ключи часто добавляют из соображений эффективности, стремясь избавиться от составных ключей или ключевых полей неудобных типов, например, строковых. Так мы и поступим. Добавим в каждую из таблиц суррогатный числовой ключ.
В результате мы получим следующий набор таблиц, соответствующих описываемым сущностям.
Понимая, с какой предметной областью имеем дело, мы знаем, что наши сущности существуют не сами по себе - они связаны некоторыми отношениями, которые мы обозначили выше. Но как их связать технически? Тут не обойтись без введения дополнительных полей и даже дополнительных таблиц. Разберемся с отношениями между сущностями по порядку.
Чтобы отнести ученика к некоторому классу, заведем в таблице “Ученик” дополнительное поле Номер класса. (Понятно, что его тип должен полностью совпадать с типом поля Номер класса в таблице “Класс”.) Теперь мы можем связать таблицы “Ученик” и “Класс” по совпадающим значениям полей Номер класса (мы не случайно назвали эти поля одинаково, на практике так часто поступают, чтобы легко ориентироваться в связывающих полях). Заметим, что одной записи в таблице “Класс” может соответствовать много записей в таблице “Ученик” (и на практике скорее всего соответствует - трудно представить себе класс из одного ученика). О таких таблицах говорят, что они связаны отношением “один ко многим ”. А поле Номер класса в таблице “Ученик” называют внешним ключом . Как видим, назначение внешних ключей - связывание таблиц. Отметим, что внешний ключ всегда ссылается на первичный ключ связанной таблицы (т.е. внешний ключ находится на стороне “многих”). Связанный с внешним первичный ключ называют родительским , хотя этот термин используется реже.
Проиллюстрируем сказанное схемой в стиле Microsoft Access (подробнее о “Схеме данных” Access написано в статье “Описание данных” 2).
Теперь вспомним об учителях и предметах. Анализируя предметную область (только так - ведь истинное положение вещей из самой формальной модели извлечь невозможно), мы замечаем, что тип связи между сущностями “учитель” и “предмет” иной, нежели рассмотренный выше. Ведь не только один предмет могут вести много учителей, но и один учитель может вести много предметов. Таким образом, между этими сущностями имеется связь “многие ко многим ”. Тут уже не обойтись введением дополнительных полей (попробуйте!). Связи “многие ко многим” всегда разрешаются посредством введения дополнительной таблицы. А именно, организуем таблицу “Учитель-Предмет”, имеющую следующую структуру:
Таблица “Учитель-Предмет”
Эта таблица имеет составной ключ, образованный из двух ее полей. И таблица “Учитель”, и таблица “Предмет” связаны с данной таблицей отношением “один ко многим” (разумеется, в обоих случаях “многие” находятся на стороне “Учитель-Предмет”). Соответственно, в таблице “Учитель-Предмет” имеются два внешних ключа (оба - части составного первичного ключа, что не воспрещается), служащие для связи с соответствующими таблицами.
На практике, помимо рассмотренных отношений “один ко многим” и “многие ко многим”, встречается и отношение “один к одному ”. С точки зрения теории такое отношение интереса не представляет, так как две таблицы, связанные отношением “один к одному”, всегда можно просто объединить в одну. Тем не менее в реальных базах данных отношение “один к одному” применяется для оптимизации обработки данных. Проиллюстрируем сказанное примером.
Допустим, мы храним очень много разнообразной информации о людях - данные их всевозможных документов, телефоны, адреса и пр. Скорее всего боRльшая часть этих данных будет использоваться очень редко. А часто нам потребуются лишь фамилия, имя, отчество и телефон. Тогда имеет смысл организовать две таблицы и связать их отношением “один к одному”. В одной (небольшой) таблице хранить часто используемую информацию, в другой - остальную. Естественно, что таблицы, связанные отношением “один к одному”, имеют один и тот же первичный ключ.
Правила целостности
Реляционная модель определяет два общих правила целостности базы данных: целостность объектов и ссылочная целостность.
Правило целостности объектов очень простое. Оно требует, чтобы первичные ключи таблиц не содержали неопределенных (пустых) значений .
Правило ссылочной целостности требует, чтобы внешние ключи не содержали несогласованных с родительскими ключами значений . Возвращаясь к рассмотренному выше примеру, мы должны потребовать, например, чтобы ученики относились лишь к классу, номер которого указан в таблице “Классы”.
Большинство СУБД умеют следить за целостностью данных (разумеется, это требует соответствующих усилий и от разработчика на этапе описания структур данных). В частности, для поддержания ссылочной целостности используются механизмы каскадирования операций. Каскадирование подразумевает, в частности, то, что при удалении записи из “родительской” таблицы, связанной с другой таблицей отношением “один ко многим”, из таблицы “многих” автоматически (самой СУБД, без участия пользователя) удаляются все связанные записи. И это естественно, ведь такие записи “повисают в воздухе”, они более ни с чем не связаны.
Индексация
Индексация - крайне важная с точки зрения практического применения, но факультативная с позиции чистой теории вещь. Основное назначение индексации - оптимизация (убыстрение) поиска (и, соответственно, некоторых других операций с базой данных). Индексация в любом случае требует дополнительных ресурсов (на физическом уровне чаще всего создаются специальные индексные файлы). Операции, связанные с модификацией данных, индексация может даже замедлять, поэтому индексируют обычно редко изменяемые таблицы, в которых часто производится поиск.
Индексный файл очень похож на индекс обычной книги. Для каждого значения индекса хранится список строк таблицы, в которых содержится данное значение. Соответственно, для поиска не надо просматривать всю таблицу - достаточно заглянуть в индекс. Зато при модификации записей может потребоваться перестроить индекс. И на это уходит дополнительное время.
Разумеется, и речи не идет о том, чтобы излагать теорию реляционных баз данных в рамках базового курса информатики! Тем не менее эта статья очень важна для нашей энциклопедии, поскольку в данном случае мы имеем дело с материалом, который не может быть в полном объеме изложен на уроках, но учитель владеть им должен. Почему?
Во-первых, потому что ряд понятий изучаются как раз в рамках базового курса. Это и табличное представление данных, и ключи таблиц. А все мы знаем, что очень трудно грамотно и точно изложить лишь некоторые понятия, не представляя общей картины.
Во-вторых, выполняя с детьми простые запросы к базам данных (соответствующий материал изложен в статье “Обработка данных” 2), необходимо иметь дело с правильными с точки зрения реляционной теории таблицами. Не требуется объяснять ученикам, что эти таблицы правильные, а “вот если бы…, то таблица была бы неправильной”, но недопустимо использовать плохие примеры.
В профильном курсе информатики ситуация может быть принципиально иной. Важнейшая и крайне продуктивная форма работы в профильных классах - проектная. В рамках учебных проектов можно и нужно разрабатывать несложные базы данных, и здесь не обойтись без основ изложенной теории. Необходимо, однако, учитывать следующее:
Моделируемые предметные области должны быть не слишком большими;
Они должны быть очень хорошо знакомы учащимся (в этом смысле изрядно поднадоевший всем проект “Школа” - не худший выбор!);
Наивно ожидать, что, прослушав основы теории, ученики смогут что-то спроектировать сами. Каждый шаг необходимо проходить вместе с ними, подробно аргументируя свои действия.
База данных (БД) - это поименованная совокупность структурированных данных, относящихся к определенной предметной области и предназначенных для хранения, накопления и обработки с помощью ЭВМ.
Реляционная База Данных (РБД) - это набор отношений, имена которых совпадают с именами схемотношений в схеме БД.
Основные понятия реляционных баз данных:
· Тип данных – тип значений конкретного столбца.
· Домен (domain) – множество всех допустимых значений атрибута.
· Атрибут (attribute) – заголовок столбца таблицы, характеризующий поименованное свойство объекта, например, фамилия студента, дата оформления заказа, пол сотрудника и т.п.
· Кортеж – строка таблицы, представляющая собой совокупность значений логически связанных атрибутов.
· Отношение (relation) – таблица, отражающая информацию об объектах реального мира, например, о студентах, заказах, сотрудниках, жителях и т.д.
· Первичный ключ (primary key) – поле (или набор полей) таблицы, однозначно идентифицирующий каждую из ее записей.
· Альтернативный ключ – это поле (или набор полей), несовпадающее с первичным ключом и уникально идентифицирующий экземпляр записи.
· Внешний ключ – это поле (или набор полей), чьи значения совпадают с имеющимися значениями первичного ключа другой таблицы. При связи двух таблиц с первичным ключом первой таблицы связывается внешний ключ второй таблицы.
· Реляционная модель данных (РМД) - организация данных в виде двумерных таблиц.
Каждая реляционная таблица должна обладать следующими свойствами:
1. Каждая запись таблицы уникальна, т.е. совокупность значений по полям не повторяется.
2. Каждое значение, записывается на пересечении строки и столбца - является атомарным (неразделимым).
3. Значения каждого поля должны быть одного типа.
4. Каждое поле имеет уникальное имя.
5. Порядок расположения записей несущественен.
Основные элементы БД:
Поле - элементарная единица логической организации данных. Для описания поля используются следующие характеристики:
· имя, например, Фамилия, Имя, Отчество, Дата рождения;
· тип, например, строковый, символьный, числовой, датовый;
· длина, например, в байтах;
· точность для числовых данных, например, два десятичных знака для отображения дробной части числа.
Запись - совокупность значений логически связанных полей.
Индекс – средство ускорения операции поиска записей, использующееся для установки связей между таблицами. Таблица, для которой используется индекс, называют индексированной. При работе с индексами необходимо обращать внимание на организацию индексов, являющуюся основой для классификации. Простой индекс представлен одним полем или логическим выражением, обрабатывающим одно поле. Составной индекс представлен несколькими полями с возможностью использования различных функций. Индексы таблицы хранятся в индексном файле.
Целостность данных – это средство защиты данных по полям связи, позволяющее поддерживать таблицы в согласованном (непротиворечивом) состоянии (то есть не допускающее существование в подчиненной таблице записей, не имеющих соответствующих записей в родительской таблице).
Запрос – сформулированный вопрос к одной или нескольким взаимосвязанным таблицам, содержащий критерии выборки данных. Запрос осуществляется с помощью структурированного языка запросов SQL (Srtructured Query Language). В результате выборки данных из одной или нескольких таблиц может быть получено множество записей, называемое представлением.
Представление данных – сохраняемый в базе данных именованный запрос на выборку данных (из одной или нескольких таблиц).
Представление, по существу, является временной таблицей, формируемой в результате выполнения запроса. Сам запрос может быть направлен в отдельный файл, отчет, временную таблицу, таблицу на диске и т.п.
Отчет – компонент системы, основное назначение которого – описание и вывод на печать документов на основе информации из БД.
Общая характеристика работы с РБД:
Наиболее распространенная трактовка реляционной модели данных, по-видимому, принадлежит Дейту, который воспроизводит ее (с различными уточнениями) практически во всех своих книгах. Согласно Дейту реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.
В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение.
В манипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка. Заметим, что основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.
28. АЛГОРИТМИЧЕСКИЕ ЯЗЫКИ. ТРАНСЛЯТОРЫ (ИНТЕРПРЕТАТОРЫ И КОМПИЛЯТОРЫ). АЛГОРИТМИЧЕСКИЙ ЯЗЫК БЕЙСИК. СТРУКТУРА ПРОГРАММЫ. ИДЕНТИФИКАТОРЫ. ПЕРЕМЕННЫЕ. ОПЕРАТОРЫ. ОБРАБОТКА ОДНОМЕРНЫХ И ДВУХМЕРНЫХ МАССИВОВ. ФУНКЦИИ ПОЛЬЗОВАТЕЛЯ. ПОДПРОГРАММЫ. РАБОТА С ФАЙЛАМИ ДАННЫХ.
Язык высокого уровня - язык программирования, понятия и структура которого удобны для восприятия человеком.
Алгоритмический язык (Algorithmic language) - язык программирования - искусственный (формальный) язык, предназначенный для записи алгоритмов. Язык программирования задается своим описанием и реализуется в виде специальной программы: компилятора или интерпретатора. Примерами алгоритмических языков служат – Borland Pascal, C++, Basic и т.д.
Основные понятия алгоритмического языка:
Состав языка :
Обычный разговорный язык состоит из четырех основных элементов: символов, слов, словосочетаний и предложений. Алгоритмический язык содержит подобные элементы, только слова называют элементарными конструкциями, словосочетания - выражениями, предложения - операторами.
Символы , элементарные конструкции, выражения и операторы составляют иерархическую структуру, поскольку элементарные конструкции образуются из последовательности символов.
Выражения - это последовательность элементарных конструкций и символов,
Оператор - последовательность выражений, элементарных конструкций и символов.
Описание языка:
Описание символов заключается в перечислении допустимых символов языка. Под описанием элементарных конструкций понимают правила их образования. Описание выражений - это правила образования любых выражений, имеющих смысл в данном языке. Описание операторов состоит из рассмотрения всех типов операторов, допустимых в языке. Описание каждого элемента языка задается его СИНТАКСИСОМ и СЕМАНТИКОЙ.
Синтаксические определения устанавливают правила построения элементов языка.
Семантика определяет смысл и правила использования тех элементов языка, для которых были даны синтаксические определения.
Символы языка - это основные неделимые знаки, в терминах которых пишутся все тексты на языке.
Элементарные конструкции - это минимальные единицы языка, имеющие самостоятельный смысл. Они образуются из основных символов языка.
Выражение в алгоритмическом языке состоит из элементарных конструкций и символов, оно задает правило вычисления некоторого значения.
Оператор задает полное описание некоторого действия, которое необходимо выполнить. Для описания сложного действия может потребоваться группа операторов.
В этом случае операторы объединяются в Составной оператор или Блок. Действия , заданные операторами, выполняются над данными. Предложения алгоритмического языка, в которых даются сведения о типах данных, называются описаниями или неисполняемыми операторами. Объединенная единым алгоритмом совокупность описаний и операторов образует программу на алгоритмическом языке. В процессе изучения алгоритмического языка необходимо отличать алгоритмический язык от того языка, с помощью которого осуществляется описание изучаемого алгоритмического языка. Обычно изучаемый язык называют просто языком, а язык, в терминах которого дается описание изучаемого языка - Метаязыком .
Трансляторы - (англ. translator - переводчик) - это программа-переводчик. Она преобразует программу, написанную на одном из языков высокого уровня, в программу, состоящую из машинных команд.
Программа, написанная на каком-либо алгоритмическом языке высокого уровня, не может быть непосредственно выполнена на ЭВМ. ЭВМ понимает только язык машинных команд. Следовательно, программа на алгоритмическом языке должна быть переведена (транслирована) на язык команд конкретной ЭВМ. Такой перевод осуществляется автоматически специальными программами-трансляторами, создаваемыми для каждого алгоритмического языка и для каждого типа компьютеров.
Существуют два основных способа трансляции - компиляция и интерпретация.
1.Компиляция: Компилятор (англ. compiler - составитель, собиратель) читает всю программу целиком, делает ее перевод и создает законченный вариант программы на машинном языке, который затем и выполняется.
При компиляции вся исходная программа сразу превращается в последовательность машинных команд. После этого полученная результирующая программа выполняется ЭВМ с имеющимися исходными данными. Достоинство такого способа состоит в том, что трансляция выполняется один раз, а (многократное) выполнение результирующей программы может осуществляться с большой скоростью. Вместе с тем результирующая программа может занять в памяти ЭВМ очень много места, так как один оператор языка при трансляции заменяется сотнями или даже тысячами команд. Кроме того, отладка и видоизменения транслированной программы весьма затруднены.
2. Интерпретация: Интерпретатор (англ. interpreter - истолкователь, устный переводчик) переводит и выполняет программу строка за строкой.
При интерпретации исходная программа хранится в памяти ЭВМ почти в неизменном виде. Программа-интерпретатор декодирует операторы исходной программы по одному и тут же обеспечивает их выполнение с имеющимися данными. Интерпретируемая программа занимает в памяти компьютера мало места, ее легко отлаживать и видоизменять. Зато выполнение программы происходит достаточно медленно, поскольку при каждом исполнении заново осуществляется поочередная интерпретация всех операторов.
Откомпилированные программы работают быстрее, но интерпретируемые проще исправлять и изменять
Каждый конкретный язык ориентирован либо на компиляцию, либо на интерпретацию - в зависимости от того, для каких целей он создавался. Например, Паскаль обычно используется для решения довольно сложных задач, в которых важна скорость работы программ. Поэтому данный язык обычно реализуется с помощью компилятора.
С другой стороны, Бейсик создавался как язык для начинающих программистов, для которых построчное выполнение программы имеет неоспоримые преимущества.
Иногда для одного языка имеется и компилятор, и интерпретатор. В этом случае для разработки и тестирования программы можно воспользоваться интерпретатором, а затем откомпилировать отлаженную программу, чтобы повысить скорость ее выполнения.
Поиск
Мы можем оповещать вас о новых статьях,