Реляционная СУБД — WiKi

 

Началом второго этапа в эволюции СУБД можно считать публикации в начале 70‑х годов ряда статей Э. Кодда (Coad), в которых выдвигались, по сути, революционные идеи, существенно изменившие устоявшиеся представления о базах данных.

Будучи математиком по образованию, Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двухмерных таблиц особого вида, известного в математике как отношение (по‑английски – relationship, отсюда и название – реляционные базы данных).

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

 

Примечание.

В СУБД первого поколения для связи записей из разных файлов использовались физические указатели или адреса на диске. Это означало, что в том случае, когда в разных файлах хранится логически связанная информация, а физическая связь между этими файлами отсутствует, то для получения выборки (извлечения информации) из такой базы данных необходимо использовать низкоуровневые средства работы с файлами. В случае же реляционной базы данных сама СУБД поддерживает извлечение информации из базы данных на основе логических связей, и при работе с базой данных нет необходимости напрямую программировать обращения к файлам. Естественно, это существенно упрощает работу с базами данных.

 

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

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

 

Примечание.

На начальном этапе развития реляционных баз данных было разработано несколько языков запросов, среди которых наиболее известны QBE (Query by Example – запрос по образцу), Quel (Query Language – язык запросов) и SQL (Structured Query Language – структурированный язык запросов). Среди этих языков на сегодняшний день наибольшее распространение имеет SQL, который в 1986 г. был принят институтом ANSI (American National Standards Institute – Американский национальный институт стандартов) в качестве стандарта языков реляционных баз данных. Последнее обновление этого стандарта было принято в 1992 г., и язык запросов, соответствующий этому стандарту, обычно обозначается как SQL‑92.

 

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

 

Объектно‑ориентированные СУБД

 

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

Объектно‑ориентированный подход имеет ряд преимуществ для разработчика, из которых можно отметить следующие:

• возможность разбить систему на совокупность независимых сущностей (объектов) и провести их строгую независимую спецификацию;

• простота эволюции системы за счет таких элементов объектного подхода как наследование и полиморфизм;

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

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

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

Использование объектной модели представления данных (и, соответственно, объектно‑ориентированной СУБД) наиболее привлекательно для информационных систем корпоративного уровня, разработка которых ведется методами объектного проектирования.

 

Примечание.

Несмотря на все достоинства объектно‑ориентированных СУБД, их использование далеко не всегда оправданно. Нередко декомпозиция данных объекта не вызывает никаких проблем и вполне логична. В этом случае применение реляционной модели может быть более эффективным. Кроме того, ведущие производители реляционных СУБД IBM и Oracle доработали свои продукты (DB2 и Oracle соответственно), добавив объектную надстройку над реляционным ядром системы. Таким образом, работая с этими СУБД, можно использовать ту или иную модель данных в зависимости от конкретной ситуации. Вероятно, что в обозримом будущем рынок корпоративных систем пока останется за гибридными объектно‑реляционными СУБД.

 

⇐ Предыдущая25262728293031323334Следующая ⇒


Дата добавления: 2014-11-25; Просмотров: 659; Нарушение авторских прав?;




Правила Кодда для реляционной СУБД (РСУБД)

1. Явное представление данных (The Information Rule). Информация должна быть представлена в виде данных, хранящихся в ячейках. Данные, храня-щиеся в ячейках, должны быть атомарны. Порядок строк в реляционной таблице не должен влиять на смысл данных.

2. Гарантированный доступ к данным (Guaranteed Access Rule). К каждому элементу данных должен быть гарантирован доступ с помощью комбинации имени таблицы, первичного ключа строки и имени столбца.

3. Обработка неизвестных значений (Systematic Treatment of Null Values). Неизвестные значения NULL, отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Например, для числовых данных неизвестные значения не должны рассматриваться как нули, а для символьных данных – как пустые строки.

4. Динамический каталог данных, основанный на реляционной модели (Dynamic On-Line Catalog Based on the Relational Model). Каталог (или словарь-справочник) данных должен сохраняться в форме реляционных таблиц, и РСУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.

5. Полнота подмножества языка (Comprehensive Data Sublanguage Rule). РСУБД должна поддерживать единственный язык, который позволяет выполнять все операции над данными: определение данных (DDL, Data Definition Language), манипулирование данными (DML, Data Manipulation Language), управление доступом пользователей к данным, управление транзакциями.

6. Поддержка обновляемых представлений (View Updating Rule). Представление (view) – это хранимый запрос к таблицам базы данных. (Подробнее о представлениях рассказано в [3]). Обновляемое представление должно поддерживать все операции манипулирования дан-ными, которые поддерживают реляционные таблицы: операции вставки, модификации и удаления данных.

7. Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete). Операции вставки, модификации и удаления данных должны поддерживаться не только по отношению к одной строке таблицы, но по отношению к любому множеству строк произвольной таблицы.

8. Физическая независимость данных (Physical Data Independence). Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютера, на котором находится БД. РСУБД должна предоставлять некоторую свободу модификации способов организации базы данных в среде хранения, не вызывая необходимости внесения изменений в логическое представление данных. Это позволяет оптимизировать среду хранения данных с целью повышения эффективности системы, не затрагивая созданных прикладных программ, работающих с БД.

9. Логическая независимость данных (Logical Data Independence). Это свойство позволяет сконструировать несколько различных логических взглядов (представлений) на одни и те же данные для разных групп пользователей. При этом пользовательское представление данных может сильно отличаться не только от физической структуры их хранения, но и от концептуальной (логической) схемы данных. Оно может синтезироваться динамически на основе хранимых объектов БД в процессе обработки запросов.

10. Независимость контроля целостности (Integrity Independence). Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных. Это реализуется с помощью ограничений целостности и механизма транзакций (см. разделы 5.2 и 6.1).

11.

Реляционная субд

Независимость от распределённости (Distribution Independence). База данных может быть распределённой (может находиться на нескольких компьютерах), и это не должно оказывать влияние на приложения. Перенос базы данных на другой компьютер не должен оказывать влияние на приложения.

12. Согласование языковых уровней (Non-Subversion Rule). Не должно быть иного средства доступа к данным, отличного от стандартного языка для работы с данными. Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и целостности, которые поддерживаются языком более высокого уровня.

Основные функции реляционной СУБД

Основные функции реляционной СУБД определяются правилами Кодда. Но потребности пользователей обуславливают также следующие функции:

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

2. Обеспечение физической целостности данных. Проблема обеспечения физической целостности данных обусловлена возможностью разрушения данных в результате сбоев и отказов в работе вычислительной системы или в результате ошибок пользователей. Развитые РСУБД позволяют в большинстве случаев восстановить потерянные данные. Восстановление данных чаще всего основано на периодическом создании резервных копий БД и ведении журнала регистрации изменений (журнала транзакций) (см. раздел 5.2).

3. Управление доступом. Для многопользовательских систем актуальна проблема защиты данных от несанкционированного доступа. Каждый пользователь этой системы в соответствии со своим уровнем (приоритетом) имеет доступ либо ко всей совокупности данных, либо только к её части. Управление доступом также подразумевает предоставление прав на проведение отдельных операций над отношениями или другими объектами БД.

4. Настройка РСУБД. Настройка РСУБД обычно выполняется администратором БД, отвечающим за функционирование системы в целом. В частности, она может включать в себя следующие операции:

  • подключение внешних приложений к БД;
  • модификация параметров организации среды хранения данных с целью повышения эффективности системы;
  • изменение структуры хранимых данных или их размещения в среде хранения (реорганизация БД) для повышения производительности системы или повторного использования освободившейся памяти;
  • модификацию концептуальной схемы данных (реструктуризация БД) при изменении предметной области и/или потребностей пользователей.

Задачи администратора БД (АБД) достаточно важны, поэтому на них следует остановиться несколько подробнее.


Читайте также:

 

Началом второго этапа в эволюции СУБД можно считать публикации в начале 70‑х годов ряда статей Э. Кодда (Coad), в которых выдвигались, по сути, революционные идеи, существенно изменившие устоявшиеся представления о базах данных.

Будучи математиком по образованию, Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двухмерных таблиц особого вида, известного в математике как отношение (по‑английски – relationship, отсюда и название – реляционные базы данных).

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

 

Примечание.

В СУБД первого поколения для связи записей из разных файлов использовались физические указатели или адреса на диске. Это означало, что в том случае, когда в разных файлах хранится логически связанная информация, а физическая связь между этими файлами отсутствует, то для получения выборки (извлечения информации) из такой базы данных необходимо использовать низкоуровневые средства работы с файлами. В случае же реляционной базы данных сама СУБД поддерживает извлечение информации из базы данных на основе логических связей, и при работе с базой данных нет необходимости напрямую программировать обращения к файлам. Естественно, это существенно упрощает работу с базами данных.

 

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

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

 

Примечание.

На начальном этапе развития реляционных баз данных было разработано несколько языков запросов, среди которых наиболее известны QBE (Query by Example – запрос по образцу), Quel (Query Language – язык запросов) и SQL (Structured Query Language – структурированный язык запросов). Среди этих языков на сегодняшний день наибольшее распространение имеет SQL, который в 1986 г. был принят институтом ANSI (American National Standards Institute – Американский национальный институт стандартов) в качестве стандарта языков реляционных баз данных. Последнее обновление этого стандарта было принято в 1992 г., и язык запросов, соответствующий этому стандарту, обычно обозначается как SQL‑92.

 

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

 

Объектно‑ориентированные СУБД

 

Несмотря на большую популярность реляционных СУБД, развитие технологии управления данными на них не остановилось.

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

Объектно‑ориентированный подход имеет ряд преимуществ для разработчика, из которых можно отметить следующие:

• возможность разбить систему на совокупность независимых сущностей (объектов) и провести их строгую независимую спецификацию;

• простота эволюции системы за счет таких элементов объектного подхода как наследование и полиморфизм;

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

Объектная модель данных более близка сущностям реального мира.

Реляционная СУБД

Объекты можно сохранить и использовать непосредственно, не раскладывая по таблицам. Типы данных определяются разработчиком и не ограничены набором предопределенных типов.

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

Использование объектной модели представления данных (и, соответственно, объектно‑ориентированной СУБД) наиболее привлекательно для информационных систем корпоративного уровня, разработка которых ведется методами объектного проектирования.

 

Примечание.

Несмотря на все достоинства объектно‑ориентированных СУБД, их использование далеко не всегда оправданно. Нередко декомпозиция данных объекта не вызывает никаких проблем и вполне логична. В этом случае применение реляционной модели может быть более эффективным. Кроме того, ведущие производители реляционных СУБД IBM и Oracle доработали свои продукты (DB2 и Oracle соответственно), добавив объектную надстройку над реляционным ядром системы. Таким образом, работая с этими СУБД, можно использовать ту или иную модель данных в зависимости от конкретной ситуации. Вероятно, что в обозримом будущем рынок корпоративных систем пока останется за гибридными объектно‑реляционными СУБД.

 

⇐ Предыдущая25262728293031323334Следующая ⇒


Дата добавления: 2014-11-25; Просмотров: 658; Нарушение авторских прав?;




Почти все продукты баз данных, созданные с конца 70-х годов, основаны на подходе, который называют реляционным (relational). Большинство научных исследований в области баз данных в течение последних 25 лет проводилось в этом направлении. На самом деле, реляционный подход представляет собой основную тенденцию сегодняшнего рынка, и реляционная модель – единственная существенная разработка в истории развития баз данных.

Реляционная система – это система, основанная на следующих принципах:

1) данные для пользователя передаются в виде таблиц ;

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

Причина, по которой такие системы называют реляционными, в том, что английский термин «relation» (отношение), – это математическое название для таблицы. Поэтому на практике термины «отношение» и «таблица» можно считать синонимами.

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

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

Примеры коммерческих продуктов, которые можно отнести к перечисленным категориям.

Системы инвертированных списков: CA-DATACOM/DB компании Computer Associates International Inc. (ранее был известен как DATACOM/DB компании Applied Data Research).

Иерархические системы: IMS корпорации IBM.

Сетевые: CA-IDMS/DB компании Computer Associates International Inc. (ранее был известен как IDMS компании Cullinet Software Inc.).

Первые реляционные продукты начали появляться в конце 1970-х— начале 1980-х годов. Существует, возможно, более 200 коммерческих реляционных продуктов, предназначенных для работы с любым программным и аппаратным обеспечением. Среди них DB2 корпорации IBM; Rdb/VMS корпорации Digital Equipment; ORACLE корпорации Oracle; INGRES компании Ingres Division of The ASK Group Inc.; SYBASE компании Sybase Inc. и многие другие.

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

– Дедуктивные СУБД.

– Экспертные СУБД.

– Расширяемые СУБД.

– Объектно-ориентированные СУБД.

– Семантические СУБД.

– Универсальные реляционные СУБД.

50. Уравнения Лапласа и Пуассона. Граничные условия на поверхности раздела сред с различными электрическими и магнитными свойствами.

Рассмотрение уравнений электромагнитного поля, записанных в дифференциальной форме в выбранной системе координат, показывает, что величины H, E, B, D должны быть непрерывными функциями координат, так как в противном случае их производные не существуют. Функции H, E, B, D могут быть разрывными в точках на границах раздела сред с различными электрическими или магнитными свойствами, а также в точках поверхностей с весьма тонкими распределенными на них слоями зарядов или токов.

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

Рассмотрим поведение поля на границе раздела двух однородных и изотропных сред с различными электрическими и магнитными свойствами.

В каждой из сред поле будем характеризовать векторами X, Y, связанными между собой соотношением Y — aX, где a — скалярная величина, и удовлетворяющими уравнениям rot X =0, div Y =0, или в интегральной форме: ?

X dl — 0, ? Y ds — 0 (рис. 23.7).

Ls

Пусть вектор X в первой среде у поверхности раздела образует с нормалью к ней угол 01. Определим соответствующий угол 02 во второй среде. Для линейного интеграла ? X dl по контуру abcda имеем: ? X dl — ll

— X1 sin 01-ab — X2 sin 02 cd — 0, если bc и ad бесконечно малы по сравнению с ab и cd.

Ввиду того, что ab — cd, получаем:

Т. е. на поверхности раздела равны касательные составляющие вектора X.

Вообразим замкнутую поверхность, образованную плоскими поверхностями s1 и s2, следы которых в плоскости рисунка суть линии ab и cd, и цилиндрической поверхностью, пересекающейся с плоскостью рисунка по линиям bc и ad. Поток вектора Y сквозь эту замкнутую поверхность равен нулю, так как внутри поверхности нет источников поля Y. Пренебрегая потоком сквозь бесконечно малую цилиндрическую поверхность, получаем

S1 s2

Откуда, принимая во внимание, что s1 — s2, находим

Т. е. на поверхности раздела равны нормальные составляющие вектора Y.

Разделив равенство (*) на (**), с учетом соотношения У1 — a1X1 и Y2 — a2X2, получаем условие преломления линий при переходе их из одной среды в другую:

Если линии вектора X нормальны к поверхности раздела, то векторы Y будут одинаковы в обеих средах: Y1 — Y2, но вектор X на поверхности раздела скачком изменяет свое значение, так как

Понимая под функцией X одну из величин E, H, а под функцией Y — D, Jили B, можем записать соотношения, связывающие их касательные и нормальные составляющие на поверхности раздела двух сред с различными свойствами, характеризуемыми скалярной величиной a, равной —, у или ц.

Полученные условия непрерывности соответствующих составляющих величин E, H, D, J, B на поверхности раздела двух сред сохраняются также и в случае

Анизотропных сред, свойства которых характеризуются тензорной величиной (a). Однако условия преломления линий при переходе их из одной среды в другую принимают более сложный вид.

В некоторых случаях на границах раздела сред с различными свойствами размещаются источники поля, такие как электрические заряды с поверхностной плотностью а и подводимые извне сторонние токи с линейной плотностью j. В этих условиях граничные условия видоизменяются, так как интегралы J Dds, J H dl уже нельзя приравнять к нулю.

51. Нагрузочная характеристика и КПД трансформатора.

Эквивалентная схема вторичной обмотки Нагрузочная кривая трансформатора

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

Реляционная СУБД

Но этого не будет.

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

При номинальном значении тока имеются отличия от ЭДС во вторичной обмотке. Нагрузочная характеристика (зависимость напряжения на выходе от потребляемого тока) является важной для любого источника.

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

(8)

КПД трансформатора в рабочем режиме складывается из полезной мощности Р и

(9)

с – сталь, м – медь

КПД является функцией коэффициента нагрузки ( )

(10)

т.е. в разных режимах КПД разное. Причем функция имеет экстремум:

Рис. Зависимость КПД от коэффициента нагрузки


⇐ Предыдущая20212223242526272829


Дата публикования: 2015-01-26; Прочитано: 64 | Нарушение авторского права страницы



studopedia.org — Студопедия.Орг — 2014-2018 год.(0.003 с)…

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *