Реляционная модель данных. Получение реляционной схемы из ER-диаграммы.
Реляционная модель данныхявляется удобной и наиболее привычной формой представления данных в виде таблицы. В отличие от иерархической и сетевой моделей, такой способ представления: 1) понятен пользователю-непрограммисту; 2) позволяет легко изменить схему – присоединять новые элементы данных и записи без изменения соответствующих подсхем; 3) обеспечивает необходимую гибкость при обработке непредвиденных запросов. Одним из основных преимуществ реляционной модели является ее однородность. Основными понятиями, с помощью которых определяется реляционная модель, являются следующие: домен, отношение, кортеж, кардинальность, атрибуты, степень, первичный ключ. Домен – это совокупность значений, из которой берутся значения соответствующих атрибутов определенного отношения. С точки зрения программирования, домен – это тип данных, определяемый системой (стандартный) или пользователем. Кортеж – таблица. Кардинальность – количество строк в таблице. Атрибут – поле, столбец таблицы. Степень отношения – количество полей, столбцов. Первичный ключ – это столбец или некоторое подмножество столбцов, которые уникально, т.е. единственным образом определяют строки. Внешний ключ – это столбец или подмножество одной таблицы, который может служить в качестве первичного ключа для другой таблицы.
Модель предъявляет к таблицам следующие требования:
1.данные в ячейках таблицы должны быть структурно неделимыми; 2.данные в одном столбце должны быть одного типа;
3.каждый столбец должен быть уникальным (недопустимо дублирование столбцов);
4.столбцы размещаются в произвольном порядке;
5.строки размещаются в таблице также в произвольном порядке;
6.столбцы имеют уникальные наименования.
1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.
2. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам – не могут. Если атрибут является множественным, то для него строится отдельное отношение.
3. Компоненты уникального идентификатора сущности превращаются в первичный ключ. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, то к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей. 4. Связи «многие к одному» и «один к одному» становятся внешними ключами. Т.е. создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ.
5. Индексы создаются для первичного ключа (уникальный индекс), а также внешних ключей и тех атрибутов, которые будут часто использоваться в запросах. 6. Если в концептуальной схеме присутствуют подтипы, то возможны два варианта. Все подтипы хранятся в одной таблице, которая создается для самого внешнего супертипа, а для подтипов создаются представления. В таблицу добавляется, по крайней мере один столбец, содержащий код типа, и он становится частью первичного ключа. Во втором случае для каждого подтипа создается отдельная таблица (для более нижних – представления) и для каждого подтипа первого уровня супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы – столбцы супертипа). 7. Если остающиеся внешние ключи все принадлежат одному домену, т.е. имеют общий формат, то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различных связей. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи. Если результирующие внешние ключи не относятся к одному домену, то для каждой связи, покрываемой дугой исключения, создаются явные столбцы внешних ключей.
Классификация режимов работы с базой данных (БД)
Такая отличительная особенность БД, как многоцелевое параллельное использование данных, предопределяет наличие средств, обеспечивающих практически одновременный и независимый доступ к одним и тем же данным. Причем сама база может быть размещена на одном или нескольких компьютерах. Свойства «идеальной» системы управления распределенными базами данных: • прозрачность относительно расположения данных: СУБД должна представлять все данные так, как если бы они были локальными;
• гетерогенность системы: СУБД должна работать с данными, которые хранятся в системах с различной архитектурой и производительностью (независимость от СУБД); • прозрачность относительно сети: СУБД должна одинаково работать в условиях разнородных сетей;
• поддержка распределенных запросов: пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах; • поддержка распределенных изменений: пользователь должен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных системах;
• поддержка распределенных транзакций: СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов как в отдельных системах, так и в сети; • безопасность: СУБД должна обеспечить защиту все распределенной БД от несанкционированного доступа;
• универсальность доступа: СУБД должна обеспечивать единую методику доступа ко всем данным. Однако ни одна из существующих СУБД не достигает этого идеала вследствие следующих практических проблем:
• низкая и несбалансированная производительность сетей передачи данных, что в распределенных транзакциях сильно снижает общую производительность обработки; • обеспечение целостности данных в распределенных транзакциях базируется на принципе «все или ничего» и требует специального протокола двухфазного завершения транзакций, что приводит к длительной блокировке изменяемых данных; • необходимо обеспечить совместимость данных стандартного типа, для хранения которых в разных системах используются разные физические форматы и кодировки; • выбор схемы размещения сетевых каталогов. Если каталог будет храниться в одной системе, то удаленный доступ будет замедлен. Если будет размножен – изменения придется распространять и синхронизировать;
• необходимо обеспечить совместимость СУБД разных типов и поставщиков; • увеличение потребности в ресурсах для координации работы приложений с целью обнаружения и устранения тупиковых ситуаций в распределенных транзакциях. Именно указанные причины определили на практике частичность и «этапность» введения в СУБД тех или иных возможностей распределенной обработки данных. В простейшем случае пользователь имеет возможность обращаться по сети к записям в БД, размещенным на других компьютерах. В других случаях СУБД сама производит аутентификацию удаленного клиента и устанавливает сетевые соединения. В общем случае режимы работы с БД можно классифицировать по следующим признакам: • многозадачность – однопользовательский или многопользовательский; • правило обслуживания запросов – последовательное или параллельное; • схема размещения данных – централизованная или распределенная БД. Следует отметить, что общая тенденция развития технологий обработки данных вполне соответствует этапам развития средств вычислительной техники и информационных технологий, и в первую очередь – сетевых. В этом смысле следует выделить два класса: системы распределенной обработки данных и системы распределенных баз данных. Системы распределенной обработки данных в основном отражают структуру и свойства многопользовательских операционных систем с базой данных, размещенной на большом центральном компьютере (мейнфрейме). Еще до недавнего времени это был единственно возможный вариант вычислительной среды для реализации больших баз данных. Клиентские места в этом случае реализовывались в виде терминалов или мини-ЭВМ, обеспечивающих в основном ввод-вывод данных и не имеющих собственных вычислительных ресурсов для функционально-ориентированной обработки получаемых данных. Развитие сетевых технологий в сочетании с широким распространением персональных ЭВМ и внедрением стандарта открытых систем привело к появлению систем баз данных, размещаемых в сети разнотипных компьютеров. Такие системы распределенных баз данных обеспечивают обработку распределенных запросов, когда при обработке одного запроса используются ресурсы базы, размещенные на различных ЭВМ сети. Система распределенных баз данных состоит из узлов, каждый из которых является СУБД, а узлы взаимодействуют между собой так, что база данных любого узла будет доступна пользователю, как если бы она была локальной. Соответственно, программы, обеспечивающие целевую (функциональную) обработку данных, могут быть организованы таким образом, чтобы обеспечить более эффективное использование совокупных вычислительных ресурсов за счет специализированного разделения функций между центральным процессором СУБД и клиентскими функционально-ориентированными процедурами. Для «типового» приложения обработки данных можно выделить следующие группы (уровни) функций: • ввод и отображение данных: внешний (пользовательский) уровень реализации целевой функциональной обработки и представления (Presentation logic);
• функциональная обработка, реализующая алгоритм решения задач пользователя. Соответствующие «бизнес-правила» реализуются обычно средствами высокоуровневого языка программирования или расширенного языка манипулирования данными типа ADABAS Natural или 4-GL (Business logic);
• манипулирование данными БД в рамках приложения, которое обычно реализуется средствами SQL (Database logic);
• управление данными и другими ресурсами БД, реализуемое специализированными (внутренними) средствами конкретной СУБД обычно в рамках файловой системы ОС; • управление процессами обработки: связывание и синхронизация процессов обработки данных разного уровня.
Технологии обработки данных
1) модель «клиент-сервер» - предполагает наличие программного компонента - потребителя какого-либо сервиса - клиента, и программного компонента - поставщика этого сервиса – сервера.
2) распределенная обработка данных.Общая тенденция развития технологий обработки данных соответствует этапам развития средств вычислительной техники и информационных технологий, и в первую очередь, - сетевых. Следует выделить 2 класса: системы распределенной обработки данных и системы распределенных баз данных Системы распределенной обработки данных в основном отражают структуру и свойства многопользовательских операционных систем с базой данных, размещенной на большом центральном компьютере (мэйнфрейме) Системы распределенных баз данных используется в сети разнотипных компьютеров, обеспечивают обработку распределенных запросов, когда при обработке одного запроса используются ресурсы базы, размещенные на различных ЭВМ сети. Состоит из узлов, каждый из которых является СУБД, а узлы взаимодействуют между собой так, что БД любого узла будет доступна пользователю, как если бы она была локальной. Функции «типового» приложения обработки данных: 1. ввод и отображение данных: внешний (пользовательский) уровень реализации целевой функциональной обработки и представления
2. функциональная обработка, реализующая алгоритм решения задач пользователя. Соответствующие «бизнес-правила» реализуются обычно средствами высокоуровневого языка программирования или расширенного языка манипулирования типа ADABAS Natural или 4-GL (business logic)
3. манипулирование данными БД в рамках приложения, которое обычно реализуется средствами SQL
4. управление данными и другими ресурсами БД, реализуемое специализированными (внутренними) средствами конкретной СУБД обычно в рамках файловой системы ОС 5. управление процессами обработки: связывание и синхронизация процессов обработки данных разного уровня
Целостность базы данных (БД). Понятие транзакции.
Применение СУБД для работы с интегрированными БД выявило особую важность проблемы целостности БД. Под целостностью БД понимают правильность и непротиворечивость ее содержимого. Нарушение целостности может быть вызвано, например, ошибками и сбоями, так как в этом случае система не в состоянии обеспечить нормальную обработку или выдачу правильных данных. Рассмотрим два аспекта целостности – на уровне отдельных объектов и операций и на уровне базы данных в целом. Первый аспект целостности обеспечивается на уровне структур данных и отдельных операторов языковых средств СУБД. При нарушении такой целостности (например, ввод значения больше 10 в столбец «Семестр» таблицы «Учебный план» БД «Сессия») соответствующий оператор отвергается. Некоторые ограничения целостности не нужно выражать в ясном виде, поскольку они встроены в структуры данных. Например, в СУБД, поддерживающей структуры, составленные из записей, каждый экземпляр записи в БД должен отображать спецификацию типа записи. Это означает, что все поля, специфицированные в описании типа, должны быть представлены в каждом экземпляре записи, а значение, заносимое в отдельное поле, должно иметь соответствующий описанию тип данных. Часто же база может иметь такие ограничения целостности, которые требуют обязательного выполнения не одной, а нескольких операций. Для иллюстрации примеров рассмотрим функциональные возможности учебной БД «Сессия», добавив в таблицу «Кадровый состав» столбец Нагрузка для решения дополнительной задачи – расчета общей годовой нагрузки преподавателей (в часах учебной работы). Тогда любая операция по внесению изменений или добавления данных в столбец ID_Преподаватель таблицы «Учебный план» должна сопровождаться соответствующим изменением данных в столбце Нагрузка. Если после внесения изменений в столбец ID_преподаватель произойдет сбой, то БД окажется в нецелостном состоянии. Для обеспечения целостности в случае ограничений на базу данных, а не какие-либо отдельные операции, служет аппарат транзакций. Транзакция – неделимая с точки зрения воздействия на БД последовательность операторов манипулирования данными (чтения, удаления, вставки, модификации), такая, что:
1) либо результаты всех операторов, входящих в транзакцию, отображаются в БД;
2) либо воздействие всех операторов полностью отсутствует. При этом для поддержания ограничений целостности на уровне БД допускается их нарушение внутри транзакции так, чтобы к моменту завершения транзакции условия целостности были соблюдены. Для обеспечения контроля целостности каждая транзакция должна начинаться при целостном состоянии БД и должна сохранить это состояние целостным после своего завершения. Если операторы, объединенные в транзакцию, выполняются, то происходит нормальное завершение транзакции, и БД переходит в обновленное (целостное) состояние. Если же происходит сбой при выполнении транзакции, то происходит так называемый откат к исходному состоянию БД.
Модели транзакций. Рассмотрим две модели транзакций, используемые в большинстве коммерческих СУБД: модель автоматического выполнения транзакций и модель управляемого выполнения транзакций, обе основаны на инструкциях языка SQL – COMMIT и ROLLBACK.
Автоматическое выполнение транзакций.В стандарте ANSI/ISO зафиксировано, что транзакция автоматически начинается с выполнения пользователем или программой первой инструкции SQL. Далее происходит последовательное выполнение инструкций до тех пор, пока транзакция не завершается одним из двух способов:
• инструкцией COMMIT, которая выполняет завершение транзакции: изменения, внесенные в БД, становятся постоянными, а новая транзакция начинается сразу после инструкции COMMIT;
• инструкцией ROLLBACK, которая отменяет выполнение текущей транзакции и возвращает БД к состоянию начала транзакции, новая транзакция начинается сразу после инструкции ROLLBACK.
Такая модель создана на основе модели, принятой в СУБД DB2.
