Экзамен Базы данных Отборное / Билеты

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

Например, сущности УПРАВЛЕНЕЦ и СОТРУДНИК могут содержать сходную информацию, поскольку обе являются ролями, которые может играть экземпляр сущности ПЕРСОНА.

Вы ор неправильно о перви но о клю а

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

Не уникальность: первичный ключ не является уникальным для каждого из экземпляров. Например, разработчик модели может считать, что номер социального страхования является уникальным для каждой ПЕРСОНЫ. Однако номер социального страхования может повторно использоваться в том случае, если первоначальный его владелец скончался.

Требуемое значение/неопределенность: первичный ключ не имеет значения для некоторых из экземпляров. Например, не каждый экземпляр сущности ПЕРСОНА будет иметь номер социального страхования. Иностранцы и маленькие дети - вот две категории людей, у которых он будет отсутствовать.

Ипользование неуда ных имен ущно тей

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

Не используйте аббревиатуры или акронимы в качестве части имени. Аббревиатуры и акронимы открыты для неправильной интерпретации и даже могут иметь разное значение в разных предметных областях.

Предостережение Не используйте имена собственные, указывающие

на конкретный экземпляр, такие как, например, Компания Интерфейс. Это неудачный выбор имени сущности, который в дальнейшем приведет к серьезным проблемам при моделировании.

Не включайте месторасположение в качестве части имени. Как правило, вам неизбежно потребуется и другое месторасположение. Имя с указанием расположения является признаком того, что вы моделируете конкретный экземпляр вместо класса сущностей.

И пользование неуда ных опи аний ущно тей

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

Не пытайтесь перефразировать имя сущности. Не используйте имя сущности в ее описании.

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

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

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

Заклю ение

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

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

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

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

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

Внешний клю (англ. foreign key) — понятие теории реляционных баз данных, относящееся к ограничениям целостности базы данных.

Неформально выражаясь, в ш й клю представляет собой дм ж тв

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

Формальное определение. Пусть R1 и R2 — две переменные отношения, не обязательно различные. Внешним ключом FK в R2 является подмножество атрибутов переменной R2 такое, что выполняются следующие требования:

1. В переменной отношения R1 имеется потенциальный ключ CK такой,

что FK и CK совпадают с точностью до переименования атрибутов (то есть переименованием некоторого подмножества атрибутов FK можно получить такое подмножество атрибутов FK’, что FK’ и CK совпадают как по именами, так и по типам атрибутов).

2.В любой момент времени каждое значение FK в текущем значении R2 идентично значению CK в некотором кортеже в текущем значении R1. Иными словами, в каждый

момент времени множество всех значений FK в R2 является (нестрогим) подмножеством значений CK в R1.

При этом для данного конкретного внешнего ключа FK → CK отношение R1, содержащее потенциальный ключ, называют глав ым, ц л вым, или р д т ль к м отношением, а отношение R2, содержащее внешний ключ, называют д ё ым, или д р м отношением.

Поддержка внешних ключей также называется соблюдением ссылочной целостности. Реляционные СУ Д поддерживают автоматический контроль ссылочной целостности.

Базовые понятия реляционных баз данных

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

Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации:

4.1.1. Тип данных

Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и "деньги".

4.1.2. Домен

Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена.

Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен "Имена" в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака).

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов "Номера пропусков" и "Номера групп" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.

4.1.3. Схема отношения, схема базы данных

Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).

Схема БД (в структурном смысле) - это набор именованных схем отношений.

4.1.4. Кортеж, отношение

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.

Отношение - это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят "отношение-схема" и "отношение-экземпляр", иногда схему отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколько отношений с данной схемой.

Однако в реляционных базах данных это не принято. Имя схемы отношения в таких базах данных всегда совпадает с именем соответствующего отношенияэкземпляра. В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается и изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных.

Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношенияэкземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения". Когда мы перейдем к рассмотрению практических вопросов организации реляционных баз данных и средств управления, мы будем использовать эту житейскую терминологию. Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.

Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

Как видно, основные структурные понятия реляционной модели данных (если не считать понятия домена) имеют очень простую интуитивную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно.

Data Definition Language (DDL) (язык описания данных) — это семейство компьютерных языков, используемых в компьютерных программах для описания структуры баз данных.

На текущий момент наиболее популярным языком DDL является SQL, используемый для получения и манипулирования данными в РСУ Д, и сочетающий в себе элементы

DDL, DML и DCL.

Функции языков DDL определяются первым словом в предложении (часто называемом запро ом), которое почти всегда является глаголом. В случае с SQL эти глаголы — «create» («создать»), «alter» («изменить»), «drop» («удалить»). Это превращает природу языка в ряд обязательных утверждений (команд) к базе данных.

Языки DDL могут существенно различаться у различных производителей СУ Д. Существует ряд стандартов SQL, установленный ISO/IEC (SQL-89,SQL-92, SQL:1999,SQL:2003, SQL:2008), но

производители СУ Д часто предлагают свои собственные «расширения» языка и, часто, не поддерживают стандарт полностью.

Data Manipulation Language (DML) (язык управления (манипулирования) данными) — это семейство компьютерных языков, используемых в компьютерных программах или пользователями баз данных для получения, вставки, удаления или изменения данных в базах данных.

На текущий момент наиболее популярным языком DML является SQL, используемый для получения и манипулирования данными в РСУ Д. Другие формы DML использованы в IMS/DL1, базах данных CODASYL (таких как IDMS), и других.

Языки DML изначально использовались только компьютерными программами, но с появлением SQL стали также использоваться и людьми.

Функции языков DML определяются первым словом в предложении (часто

называемом запро ом), которое почти всегда является глаголом. В случае с SQL эти глаголы — «insert» («вставить»), «update» («обновить»), и «delete» («удалить»). Это превращает природу языка в ряд обязательных утверждений (команд) к базе данных.

Языки DML могут существенно различаться у различных производителей СУ Д. Существует стандарт SQL, установленный ANSI, но производители СУ Д часто предлагают свои собственные «расширения» языка.

Языки DML разделяются в основном на два типа:

Procedural DMLs — описывают действия над данными.

Declarative DMLs — описывают сами данные.

Data Control Language (DCL) — язык баз данных для осуществления административных функций, присваивающих или отменяющих право (привилегию) использовать базу данных, таблицы в базе данных, а также выполнять те или иные операторы SQL.

GRANT — применяется для присвоения привилегии;

REVOKE — применяется для отмены привилегии.

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

Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование больше чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit — двухфазный протокол фиксации транзакции). Также, в некоторых системах реализованы автономные транзакции, или под-транзакции, которые являются автономной частью родительской транзакции.

Содержание

[убрать]

1 Пример транзакции

2 Свойства транзакций

3 Уровни изоляции транзакций

4Реализация

5См. также

6Примечания

[править]Пример транзакции

Пример: Необходимо перевести с банковского счёта номер 5 на счёт номер 7 сумму в 10 денежных единиц. Этого можно достичь, к примеру, приведённой последовательностью действий:

Начать транзакцию

прочесть баланс на счету номер 5

уменьшить баланс на 10 денежных единиц

сохранить новый баланс счёта номер 5

прочесть баланс на счету номер 7

увеличить баланс на 10 денежных единиц

сохранить новый баланс счёта номер 7

Окончить транзакцию

Эти действия представляют собой логическую единицу работы «перевод суммы между счетами», и таким образом, являются транзакцией. Если прервать данную транзакцию, к примеру, в середине, и не аннулировать все изменения, легко оставить владельца счёта номер 5 без 10 единиц, тогда как владелец счета номер 7 их не получит.

[править]Свойства транзакций

О в ая татья: ACID

Одним из наиболее распространённых наборов требований к транзакциям и транзакционным системам является набор ACID

(Atomicity, Consistency, Isolation, Durability). Вместе с тем,

существуют специализированные системы с ослабленными транзакционными свойствами[1].

[править]Уровни изоляции транзакций

В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции — единственный. Однако в реальности, по соображениям производительности и для выполнения некоторых специальных задач, СУ Д предоставляют различные уровни изоляции транзакций. Уровни описаны в порядке увеличения изоляции транзакций и надёжности работы с данными

0 — Неподтверждённое тение (Read Uncommitted,

Dirty Read, грязное чтение) — чтение незафиксированных изменений своей транзакции и конкурирующих транзакций, возможны нечистые, неповторяемые чтения и фантомы

1 — одтверждённое тение (Read Committed) —

чтение всех изменений своей транзакции и зафиксированных изменений конкурирующих транзакций, нечистые чтения невозможны, возможны неповторяемые чтения и фантомы

2 — овторяемое тение (Repeatable Read, Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесённые конкурирующими транзакциями после начала своей, недоступны, нечистые и неповторяемые чтения невозможны, возможны фантомы

3 — Упорядо енный — (Serializable,

сериализуемый) — упорядоченные (сериализуемые) транзакции. Идентичен ситуации, при которой транзакции выполняются строго последовательно, одна после другой. То есть

транзакции, результат действия которых не зависит от порядка выполнения шагов транзакции (запрещено чтение всех данных, изменённых с начала транзакции, в том числе и своей транзакцией). Фантомы невозможны.

Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы их поддерживать.

В СУ Д уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для одной конкретной транзакции. По умолчанию в большинстве баз данных используется уровень 1 (Read Committed). Уровень 0 используется в основном для отслеживания изменений длительных транзакций или для чтения редко изменяемых данных. Уровни 2 и 3 используются при повышенных требованиях к изолированности транзакций.

[править]Реализация

Полноценная реализация уровней изоляции и свойств ACID представляет собой нетривиальную задачу. Обработка поступающих данных приводит к большому количеству маленьких изменений, включая обновление как самих таблиц, так и индексов. Эти изменения потенциально могут потерпеть неудачу: закончилось место на диске, операция занимает слишком много времени (timeout) и т. д. Система должна в случае неудачи корректно вернуть базу данных в состояние до транзакции.

Первые коммерческие СУ Д (к примеру, IBM DB2), пользовались исключительно блокировкой доступа к данным для обеспечения свойств ACID. Но большое количество блокировок приводит к существенному уменьшению производительности. Есть два популярных семейства решений этой проблемы, которые снижают количество блокировок:

Журнализация изменений (write ahead logging, WAL)

механизм теневых страниц (shadow paging)[2].

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

При у р ждающ й жур ал зац , используемой

в Sybase и MS SQL Server до версии 2005, все изменения записываются в журнал, и только после успешного завершения — в базу данных. Это позволяет СУ Д вернуться в рабочее состояние после неожиданного падения системы. Т вы тра цы содержат копии тех страниц базы данных на начало транзакции, в которых происходят изменения. Эти копии активизируются после успешного завершения. Хотя теневые страницы легче реализуются, упреждающая журнализация более эффективна[3]

Дальнейшее развитие технологий управления базами данных привело к появлению безблокировочных технологий. Идея контроля за параллельным доступом с помощью временных меток (timestamp-based concurrency control) была развита и привела к появлению многоверсионной архитектуры MVCC. Эти технологии не нуждаются ни в журнализации изменений, ни в теневых страницах. Архитектура, реализованная в Oracle 7.х и выше, записывает тары версии страниц в специальный сегмент отката, но они все ещё доступны для чтения. Если транзакция при чтении попадает на страницу, временная метка которой новее начала чтения, данные берутся из сегмента отката (то есть используется «старая» версия). Для поддержки такой работы ведётся журнал транзакций, но в отличие от «упреждающей журнализации», он не содержит данных. Работа с ним состоит из трёх логических шагов:

1.Записать намерение произвести некоторые операции

2.Выполнить задание, копируя оригиналы изменяемых страниц в сегмент отката

3.Записать, что всё сделано без ошибок

Журнал транзакций в сочетании с гм т м тката (область, в которой хранится копия всех

изменяемых в ходе транзакции данных) гарантирует целостность данных. В случае сбоя запускается процедура восстановления, которая просматривает отдельные его записи следующим образом:

Если повреждена запись, то сбой произошёл во время проставления отметки в журнале. Значит, ничего важного не потерялось, игнорируем эту ошибку.

Если все записи помечены как успешно выполненные, то сбой произошёл между транзакциями, здесь также нет потерь.

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

Firebird вообще не имеет ни журнала изменений, ни сегмента отката, а реализует MVCC, записывая новые версии строк таблиц прямо в активное пространство данных. Также поступает MS SQL 2005. Теоретически это даёт максимальную эффективность при параллельной работе с данными, но ценой является необходимость «сборки мусора», то есть удаления старых и уже не нужных версий данных.