Вопросы для самоконтроля из лекций. ОПБД.
Системы обработки документов, а точнее, содержащейся в них информации, обычно называют информационными. Информационные системы имеют следующие особенности:
@ для обеспечения их работы нужны сравнительно низкие вычислительные мощности
@ данные, которые они используют, имеют сложную структуру
@ необходимы средства сохранения данных между последовательными запусками системы
Предметная область — часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации.
Термины в модуле (9)
Системы обработки документов, а точнее, содержащейся в них информации, обычно называют информационными. Информационные системы имеют следующие особенности:
@ для обеспечения их работы нужны сравнительно низкие вычислительные мощности
@ данные, которые они используют, имеют сложную структуру
@ необходимы средства сохранения данных между последовательными запусками системы
Предметная область — часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации.
2.1.4. Этапы развития баз данных
В 1968 году была введена в эксплуатацию первая промышленная СУБД IMS фирмы IBM.
В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных – Conference of Data System Languages (CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основополагающими для сетевой модели данных.
В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э.Ф. Коддом, который является создателем реляционной модели данных.
Развитие персональных ЭВМ и появление мощных рабочих станций и сетей ЭВМ повлияло также и на развитие технологии баз данных.
Можно выделить четыре этапа в развитии данного направления в обработке данных. Однако необходимо заметить, что всё же нет жёстких временных ограничений в этих этапах: они плавно переходят один в другой и даже сосуществуют параллельно, но тем не менее выделение этих этапов позволит более чётко охарактеризовать отдельные стадии развития технологии баз данных, подчеркнуть особенности, специфичные для конкретного этапа.
Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation – DEC), разных моделях HP (фирмы Hewlett Packard).
Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ.
Программы доступа к БД писались на различных языках и запускались как обычные «числовые программы».
Мощные операционные системы обеспечивали возможность условно параллельного выполнения всего множества задач. Эти системы можно было отнести к системам распределённого доступа, потому что база данных была централизованной, хранилась на устройствах внешней памяти одной центральной ЭВМ, а доступ к ней поддерживался от многих пользователей-задач.
Особенности этого этапа развития выражаются в следующем:
все СУБД базируются на мощных мультипрограммных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределённого доступа;
функции управления распределением ресурсов в основном осуществляются операционной системой;
поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным;
значительная роль отводится администрированию данных;
проводятся серьёзные работы по обоснованию и формализации реляционной модели данных;
проводятся теоретические работы по оптимизации запросов и управлению распределённым доступом к централизованной БД, было введено понятие транзакции;
появляются первые языки высокого уровня для работы с реляционной моделью данных, однако отсутствуют стандарты для этих первых языков.
Второй этап – «эпоха персональных компьютеров»
На этом этапе появилось множество программ, предназначенных для работы неподготовленных пользователей.
Простыми и понятными стали операции копирования файлов и перенос информации с одного компьютера на другой.
Появились программы, которые назывались системами управления базами данных и позволяли хранить значительные объёмы информации, они имели удобный интерфейс для заполнения данных и встроенные средства для генерации различных отчётов.
Эти программы позволяли автоматизировать многие учётные функции, которые раньше велись вручную.
Компьютеры стали инструментом для ведения документации и собственных учётных функций организациями и отдельными пользователями.
Это всё сыграло как положительную, так и отрицательную роль в области развития баз данных.
Кажущаяся простота и доступность персональных компьютеров и их программного обеспечения породила множество дилетантов.
Эти разработчики, считая себя знатоками, стали проектировать недолговечные базы данных, которые не учитывали многих особенностей объектов реального мира.
Было создано много систем-однодневок, которые не отвечали законам развития и взаимосвязи реальных объектов.
Однако спрос на развитые удобные программы обработки данных заставлял поставщиков программного обеспечения поставлять всё новые системы, которые принято называть настольными (desktop) СУБД.
Значительная конкуренция среди поставщиков заставляла совершенствовать эти системы, предлагая новые возможности, улучшая интерфейс и быстродействие систем, снижая их стоимость.
Наличие на рынке большого числа СУБД, выполняющих сходные функции, потребовало разработки методов экспорта-импорта данных для этих систем и открытия форматов хранения данных.
Но и в этот период появлялись любители, которые вопреки здравому смыслу разрабатывали собственные БД, используя стандартные языки программирования.
Это был тупиковый вариант, потому что дальнейшее развитие показало, что перенести данные из нестандартных форматов в новые СУБД было гораздо труднее, а в некоторых случаях требовало таких трудозатрат, что легче было бы все разработать заново.
Особенности этого этапа таковы:
все СУБД были рассчитаны на создание БД в основном с монопольным доступом (т.к. компьютер – персональный и не подсоединён к сети);
в редких случаях предполагалась последовательная работа нескольких пользователей, например, сначала оператор, который вводил бухгалтерские документы, а потом главбух, который определял проводки, соответствующие первичным документам;
большинство СУБД имели развитый и удобный пользовательский интерфейс;
большинство СУБД предлагали развитый и удобный инструментарий для разработки готовых приложений без программирования;
инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчётов, графических конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс;
Вам это всё ничего не напоминает?
Да-да, Microsoft Access.
во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний табличный вид структур данных;
при наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц;
в настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных, эти функции должны были выполнять приложения;
наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим – к отсутствию инструментальных средств администрирования БД;
требования к аппаратному обеспечению со стороны настольных СУБД были сравнительно скромными.
Яркие представители этого семейства – очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaseIV), FoxPro, Clipper, Paradox.
Также по непонятным причинам до сих пор используется уже упомянутый MS-Access, на котором, по хорошему, можно построить именно однопользовательскую БД или БД на «отдел из 2-3 человек» (и то уже могут быть проблемы).
Третий этап – распределённые базы данных
После процесса «персонализации» начался обратный процесс – интеграция.
С развитием компьютерных сетей остро встала задача согласованности данных, логически связанных друг с другом, но хранящихся и обрабатывающихся в разных местах.
Возникли задачи, связанные с параллельной обработкой транзакций – последовательностей операций над БД, переводящих её из одного непротиворечивого состояния в другое непротиворечивое состояние.
Успешное решение этих задач приводит к появлению распределённых баз данных, сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД.
Особенности данного этапа:
практически все современные СУБД обеспечивают поддержку полной реляционной модели;
большинство современных СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД на разных платформах, практически неразличим;
необходимость поддержки многопользовательской работы с базой данных и возможность децентрализованного хранения данных потребовали развития средств администрирования БД с реализацией общей концепции средств защиты данных;
потребность в реализации новых СУБД вызвала создание серьёзных теоретических трудов по оптимизации распределённых БД и работе с распределёнными транзакциями и запросами;
чтобы не потерять клиентов, которые ранее работали на настольных СУБД, практически все современные СУБД имеют средства подключения клиентских приложений, разработанных с использованием настольных СУБД, и средства экспорта данных из форматов настольных СУБД второго этапа развития;
именно к этому этапу можно отнести разработку ряда стандартов в рамках языков описания и манипулирования данными начиная с SQL89, SQL92, SQL99 (и т.д.) и технологий по обмену данными между различными СУБД, к которым можно отнести и протокол ODBC (Open DataBase Connectivity), предложенный фирмой Microsoft;
именно к этому этапу можно отнести начало работ, связанных с концепцией объектно-ориентированных БД – ООБД.
Первыми представителями СУБД, относящимся к этому этапу, можно считать Oracle7.3, Oracle 8.4 MS SQL6.5, MS SQL7.0, System 10, System 11, Informix, DB2, SQL Base и т.п.
Четвёртый этап – дальнейшее развитие
Этот этап характеризуется появлением новой технологии доступа к данным – «интернет/интранет-доступ».
Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения.
Для работы с удалённой БД используется стандартный веб-браузер.
При этом код, написанный обычно на т.н. «языках веб-программирования» (Java, PHP, Perl, C#, ASP.Net) отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа.
Удобство данного подхода привело к тому, что он стал использоваться не только для удалённого доступа к базам данных, но и для пользователей локальной сети предприятия, т.к. для подключения нового пользователя не требуется установка дополнительного клиентского программного обеспечения.
Однако алгоритмически сложные задачи рекомендуется реализовывать в архитектуре «клиент-сервер» с разработкой специального клиентского программного обеспечения.
У каждого из вышеперечисленных подходов к работе с данными есть свои достоинства и свои недостатки, которые и определяют область применения того или иного метода, и в настоящее время все подходы широко используются.
Лекции по базам данных
Медведева А.А. Конспект лекций «Основы проектирования баз данных» / А.А. Медведева. – Курган, 2015. – 64 с.
Рассмотрено на заседании ЦМК ИиТД
Протокол от___ №________________
Автор-составитель: Медведева А.А. – преподаватель ГБПОУ «КТК»
Конспект лекций содержит теоретический материал в компактной форме и представляет собой тезисы лекции, расположенные в соответствии с планом лекции. Предназначен для студентов специальностей среднего профессионального образования 09.02.04 «Информационные системы (по отраслям)», 09.02.05 «Прикладная информатика (по отраслям)».
© Медведева А.А., 2015
Пояснительная записка 4
Лекция 1. Основные понятия теории баз данных 5
Лекция 2-3. Технологии работы с базами данных 10
Лекция 4. Логическая и физическая независимость данных 14
Лекция 5. Типы моделей данных. Реляционная модель данных 17
Лекция 6. Реляционная алгебра 22
Лекция 7. Основные этапы проектирования БД 24
Лекция 8. Концептуальное проектирование БД 29
Лекция 9. Нормализация БД 34
Лекция 10. Средства проектирования структур БД 36
Лекция 11. Организация интерфейса с пользователем 42
Лекция 12. Основные понятия языка SQL 46
Лекция 13. Синтаксис операторов, типы данных 49
Лекция 14. Создание, модификация и удаление таблиц 52
Лекция 15. Операторы манипулирования данными 55
Лекция 16-17. Организация запросов на выборку данных при помощи языка SQL 56
Лекция 18. Сортировка и группировка данных при помощи языка SQL 58
Лекция 19. Функции в запросах SQL 59
Цель данного пособия оказать помощь в самостоятельной подготовке студентов изучающих основы проектирования баз данных, и способствовать формированию системного представления относительно основных теоретико-методологических вопросов.
Содержание конспекта лекций позволит более точно и правильно сформировать понимание представленных тем. Кроме того, работа с конспектом лекций определяет круг основных понятий по данному вопросу, что позволяет более качественно их освоить и быть более успешными в подготовке к промежуточной аттестации.
Лекция 1. Основные понятия теории баз данных
Основные понятия теории баз данных
История возникновения баз данных
История развития баз данных
Компьютеры были созданы для решения вычислительных задач, однако со временем они все чаще стали использоваться для построения систем обработки документов, а точнее, содержащейся в них информации. Такие системы обычно и называют информационными.
Информационные системы имеют следующие особенности:
для обеспечения их работы нужны сравнительно низкие вычислительные мощности
данные, которые они используют, имеют сложную структуру
необходимы средства сохранения данных между последовательными запусками системы, …
Другими словами, информационная система требует создания в памяти ЭВМ динамически обновляемой модели внешнего мира с использованием единого хранилища — базы данных (БД).
Предметная область — часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации.
Отличительной чертой баз данных следует считать то, что данные хранятся совместно с их описанием, а в прикладных программах описание данных не содержится. Независимые от программ пользователя данные обычно называются метаданными. В ряде современных систем метаданные, содержащие также информацию о пользователях, форматы отображения, статистику обращения к данным и др. сведения, хранятся в словаре базы данных.
Таким образом, система управления базой данных (СУБД) — важнейший компонент информационной системы. Для создания и управления информационной системой СУБД необходима в той же степени, как для разработки программы на алгоритмическом языке необходим транслятор.
Основные функции СУБД:
управление данными во внешней памяти (на дисках);
управление данными в оперативной памяти;
журнализация изменений и восстановление базы данных после сбоев;
поддержание языков БД (язык определения данных, язык манипулирования данными).
История возникновения БД
В истории вычислительной техники можно проследить развитие двух основных областей ее использования.
Первая область — применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Характерной особенностью данной области применения вычислительной техники является наличие сложных алгоритмов обработки, которые применяются к простым по структуре данным, объем которых сравнительно невелик.
Вторая область — это использование средств вычислительной техники в автоматических или автоматизированных информационных системах.
Информационная система представляет собой программно-аппаратный комплекс, обеспечивающий выполнение следующих функций:
надежное хранение информации в памяти компьютера;
выполнение специфических для данного приложения преобразований информации и вычислений;
предоставление пользователям удобного и легко осваиваемого интерфейса.
Обычно такие системы имеют дело с большими объемами информации, имеющей достаточно сложную структуру.
Важным шагом в развитии именно информационных систем явился переход к использованию централизованных систем управления файлами. С точки зрения прикладной программы, файл — это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Правила именования файлов, способ доступа к данным, хранящимся в файле, и структура этих данных зависят от конкретной системы управления файлами и, возможно, от типа файла. Система управления файлами берет на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса во внешней памяти и обеспечение доступа к данным.
Пользователи видят файл как линейную последовательность записей и могут выполнить над ним ряд стандартных операций:
создать файл (требуемого типа и размера);
открыть ранее созданный файл;
прочитать из файла некоторую запись (текущую, следующую, предыдущую, первую, последнюю);
записать в файл на место текущей записи новую, добавить новую запись в конец файла.
В разных файловых системах эти операции могли несколько отличаться, но общий смысл их был именно таким.
Главное, что следует отметить, это то, что структура записи файла была известна только программе, которая с ним работала, система управления файлами не знала ее. И поэтому для того, чтобы извлечь некоторую информацию из файла, необходимо было точно знать структуру записи файла с точностью до бита. Каждая программа, работающая с файлом, должна была иметь у себя внутри структуру данных, соответствующую структуре этого файла. Поэтому при изменении структуры файла требовалось изменять структуру программы, а это требовало новой компиляции, то есть процесса перевода программы в исполняемые машинные коды. Такая ситуация характеризовалась как зависимость программ от данных. Для информационных систем характерным является наличие большого числа различных пользователей (программ), каждый из которых имеет свои специфические алгоритмы обработки информации, хранящейся в одних и тех же файлах. Изменение структуры файла, которое было необходимо для одной программы, требовало исправления и перекомпиляции и дополнительной отладки всех остальных программ, работающих с этим же файлом. Это было первым существенным недостатком файловых систем, который явился толчком к созданию новых систем хранения и управления информацией.
Поскольку файловые системы являются общим хранилищем файлов, принадлежащих, вообще говоря, разным пользователям, системы управления файлами должны обеспечивать авторизацию доступа к файлам. В общем виде подход состоит в том, что по отношению к каждому зарегистрированному пользователю данной вычислительной системы для каждого существующего файла указываются действия, которые разрешены или запрещены данному пользователю. И отсутствие централизованных методов управления доступом к информации послужило еще одной причиной разработки СУБД.
Следующей причиной стала необходимость обеспечения эффективной параллельной работы многих пользователей с одними и теми же файлами. В общем случае системы управления файлами обеспечивали режим многопользовательского доступа. Если операционная система поддерживает многопользовательский режим, вполне реальна ситуация, когда два или более пользователя одновременно пытаются работать с одним и тем же файлом. Если все пользователи собираются только читать файл, ничего страшного не произойдет. Но если хотя бы один из них будет изменять файл, для корректной работы этих пользователей требуется взаимная синхронизация их действий по отношению к файлу.
В системах управления файлами обычно применялся следующий подход. В операции открытия файла (первой и обязательной операции, с которой должен начинаться сеанс работы с файлом) среди прочих параметров указывался режим работы (чтение или изменение). Если к моменту выполнения этой операции некоторым пользовательским процессом PR1 файл был уже открыт другим процессом PR2 в режиме изменения, то в зависимости от особенностей системы процессу PR1 либо сообщалось о невозможности открытия файла, либо он блокировался до тех пор, пока в процессе PR2 не выполнялась операция закрытия файла.
При подобном способе организации одновременная работа нескольких пользователей, связанная с модификацией данных в файле, либо вообще не реализовывалась, либо была очень замедлена.
Эти недостатки послужили тем толчком, который заставил разработчиков информационных систем предложить новый подход к управлению информацией. Этот подход был реализован в рамках новых программных систем, названных впоследствии Системами Управления Базами Данных (СУБД), а сами хранилища информации, которые работали под управлением данных систем, назывались базами или банками данных (БД и БнД).
История развития БД
Концепция БД сложилась в конце 60-х годов прошлого столетия и с тех пор постоянно развивалась.
Первый этап сложился к началу 60-х годов прошлого века и характеризуется следующими признаками:
информация преимущественно хранится в последовательных файлах на магнитных лентах;
физическая структура данных строго соответствует логической;
в качестве архива хранятся несколько копий файлов;
файлы предназначены для единственной программы;
программист планирует не только логическую, но и физическую организацию данных;
при изменении физической или логической организации данных программа должна перерабатываться.
Второй этап относится к середине 60-х годов и имеет следующие особенности:
появились внешние устройства прямого доступа, позволившие осуществить произвольный доступ к записям (прямой, индексно-последовательный);
вошли в употребление процедуры поиска записи по ключевому полю (обычно одному);
стало возможным переносить файлы на другие внешние устройства без изменения прикладных программ, что обычно обеспечивалось средствами языка управления данными соответствующей операционной системы.
Третий этап начался с конца 60-х годов. Основным достижением можно считать осознание необходимости централизации данных для доступа к ним различных приложений. При этом уменьшается избыточность и противоречивость информации, приложения используют стандартные средства доступа к данным. На этом этапе возросла сложность организации данных, был реализован эффективный поиск записей по многим ключам.
Именно на этом этапе появились первые СУБД. Прежде всего развивались теория и практика построения иерархических и сетевых СУБД. В этих моделях связи данных описываются с помощью деревьев и графов общего вида.
Четвертый этап датируется второй половиной 70-х годов. На этом этапе были реализованы следующие основные характеристики СУБД:
логическая и физическая независимость данных;
удобство развития БД;
безопасность, секретность, целостность данных;
поиск информации по различным запросам;
языковые средства для администратора, прикладного программиста, пользователя-непрофессионала.
С начала 70-х годов после публикаций Э.Кодда начались активные исследования реляционной модели данных. Основу реляционной СУБД составляют таблицы. Вплоть до 80-х годов реляционные СУБД считались перспективными, но трудными для реализации.
Новый этап в развитии СУБД наступил при появлении персональных компьютеров. На этом этапе на передний план вышли такие особенности СУБД, как:
дружественность и удобство работы пользователя (развитые диалоги, меню, оконный интерфейс, контекстная помощь);
упрощение громоздких схем СУБД за счет частичной реализации ряда свойств;
почти полный переход на реляционные СУБД;
ориентация не только на программиста, но и на пользователя-непрофессионала;
наличие средств автоматизации программирования в виде генераторов форм, меню, отчетов, запросов.
Классификация БД
Классификация БД может быть произведена по различным признакам, среди которых выделяют:
По форме представления информации: фактографические и документальные.
По типу используемой модели данных: иерархические, сетевые, реляционные.
По типологии хранения данных: локальные (централизованные) и распределённые (удалённые) БД.
Классификация не является полной. Различные источники предоставляют разнообразную классификацию.
Вопросы для самоконтроля:
Дайте определения понятиям: информационная система, предметная область.
Что называется базой данных и каково ее место в ИС?
В чем различие между данными и метаданными?
Каково назначение систем управления базами данных?
Для чего используется словарь данных?
Назовите этапы развития БД.
Какую роль в развитии технологии БД сыграло появление ПК?
Каковы функции СУБД?
Лекция 2-3. Технологии работы с базами данных
Технология "клиент – сервер"
Трехзвенная (многозвенная) архитектура "клиент – сервер"
Понятие базы данных изначально предполагало возможность решения многих задач несколькими пользователями. В связи с этим, важнейшей характеристикой современных СУБД является наличие многопользовательской технологии работы. Разная реализация таких технологий в разное время была связана как с основными свойствами вычислительной техники, так и с развитием программного обеспечения.
Централизованная архитектура
При использовании этой технологии база данных, СУБД и прикладная программа (приложение) располагаются на одном компьютере (рисунок 1). Для такого способа организации не требуется поддержки сети и все сводится к автономной работе.
Рисунок 1 — Централизованная архитектура
Многопользовательская технология работы обеспечивалась либо режимом мультипрограммирования, либо режимом разделения времени.
Архитектура "файл-сервер"
Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явились предпосылками появления новой архитектуры файл-сервер. Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных (рисунок 2).
Рисунок 2 — Архитектура "файл-сервер"
Технология "клиент – сервер"
Использование технологии " клиент – сервер " предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети).
Так, архитектура " клиент – сервер " разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL (Structured Query Language), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД.
SQL-сервер – специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети "путешествуют" только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами.
Архитектура системы представлена на рисунке 3.
Рисунок 3 — Архитектура "клиент – сервер"
Трехзвенная (многозвенная) архитектура "клиент – сервер"
Трехзвенная (в некоторых случаях многозвенная ) архитектура (N-tier или multi-tier). представляет собой дальнейшее совершенствование технологии " клиент – сервер ". Рассмотрев архитектуру " клиент – сервер ", можно заключить, что она является 2-звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД. В трехзвенной архитектуре вся бизнес-логика (деловая логика), ранее входившая в клиентские приложения, выделяется в отдельное звено, называемое сервером приложений. При этом клиентским приложениям остается лишь пользовательский интерфейс.
Схематически такую архитектуру можно представить, как показано на рисунке 4.
Рисунок 4 — Представление многоуровневой архитектуры "клиент-сервер"
Вопросы для самоконтроля:
Назовите достоинства и недостатки существующих многопользовательских технологий с базами данных.
Лекция 4. Логическая и физическая независимость данных
Архитектура базы данных
Механизм прохождения запроса к БД
Современные авторы часто употребляют термины "банк данных" и "база данных" как синонимы, однако в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г., эти понятия различаются. Там приводятся следующие определения банка данных, базы данных и СУБД:
Банк данных (БнД) — это система специальным образом организованных данных — баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.
База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.
Система управления базами данных (СУБД) — совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.
Программы, с помощью которых пользователи работают с базой данных, называются приложениями. В общем случае с одной базой данных могут работать множество различных приложений. При рассмотрении приложений, работающих с одной базой данных, предполагается, что они могут работать параллельно и независимо друг от друга, и именно СУБД призвана обеспечить работу множества приложений с единой базой данных таким образом, чтобы каждое из них выполнялось корректно, но учитывало все изменения в базе данных, вносимые другими приложениями.
Архитектура базы данных
В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации.
Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рисунке 5.
Рисунок 5 — Трехуровневая модель системы управления базой данных, предложенная ANSI
Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое "видение" данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению.
Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.
Физический уровень — собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.
Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными.
Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных.
Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных.
Процесс прохождения пользовательского запроса
Рисунок 6 иллюстрирует взаимодействие пользователя, СУБД и ОС при обработке запроса на получение данных. Цифрами помечена последовательность взаимодействий:
Рисунок 6 — Схема прохождения запроса к БД
Разумеется, механизм прохождения запроса в реальных СУБД гораздо сложнее, но и эта упрощенная схема показывает, насколько серьезными и сложными должны быть механизмы обработки запросов, поддерживаемые реальными СУБД.
Вопросы для самоконтроля:
Каким образом прикладные программы взаимодействуют с БД?
Чем банк данных отличается от базы данных?
Какие компоненты входят в состав банка данных?
Что представляет собой трехуровневая архитектура СУБД?
В чем особенность уровня внешних моделей?
В чем особенность концептуального уровня?
В чем особенность физического уровня?
Что означает логическая и физическая независимость данных?
Лекция 5. Типы моделей данных. Реляционная модель данных
Иерархическая модель базы данных
Сетевая модель базы данных
Реляционная модель базы данных
Различают три основные модели базы данных — это иерархическая, сетевая и реляционная. Эти модели отличаются между собой по способу установления связей между данными.
Иерархическая модель базы данных
Иерархические базы данных — самая ранняя модель представления сложной структуры данных. Информация в иерархической базе организована по принципу древовидной структуры, в виде отношений "предок-потомок".
Каждая запись может иметь не более одной родительской записи и несколько подчиненных.
Связи записей реализуются в виде физических указателей с одной записи на другую.
Основной недостаток иерархической структуры базы данных — невозможность реализовать отношения "многие-ко-многим", а также ситуации, когда запись имеет несколько предков.
Иерархические базы данных графически могут быть представлены как перевернутое дерево, состоящее из объектов различных уровней. Верхний уровень (корень дерева) занимает один объект, второй — объекты второго уровня и так далее.
Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись (группа), групповое отношение, база данных.
Атрибут (элемент данных) — наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.
Запись — именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи — конкретная запись с конкретным значением элементов.
Групповое отношение — иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) — подчиненными. Иерархическая база данных может хранить только такие древовидные структуры.
Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей от корневой, по иерархическому пути.
Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство. Это означает, что для запоминания любой некорневой записи в БД должна существовать ее родительская запись.
Операции над данными, определенные в иерархической модели:
Добавить в базу данных новую запись. Для корневой записи обязательно формирование значения ключа.
Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.
Удалить некоторую запись и все подчиненные ей записи.
Извлечь корневую запись по ключевому значению, допускается также последовательный просмотр корневых записей.
Извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева).
В операции ИЗВЛЕЧЬ допускается задание условий выборки.
Все операции изменения применяются только к одной "текущей" записи (которая предварительно извлечена из базы данных). Такой подход к манипулированию данных получил название "навигационного".
В иерархической БД поддерживается только целостность связей между владельцами и членами группового отношения (никакой потомок не может существовать без предка).
Сетевая модель базы данных
Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений. Связь между записью-владельцем и записью-членом также имеет вид 1:N.
Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одного группового отношения.
Операции над данными в сетевой модели БД
Добавить — внести запись в БД и, в зависимости от режима включения, либо включить ее в групповое отношение, где она объявлена подчиненной, либо не включать ни в какое групповое отношение.
Включить в групповое отношение — связать существующую подчиненную запись с записью-владельцем.
Переключить — связать существующую подчиненную запись с другой записью-владельцем в том же групповом отношении.
Обновить — изменить значение элементов предварительно извлеченной записи.
Извлечь — извлечь записи последовательно по значению ключа, а также используя групповые отношения — от владельца можно перейти к записям — членам, а от подчиненной записи к владельцу набора.
Удалить — убрать из БД запись. Если эта запись является владельцем группового отношения, то анализируется класс членства подчиненных записей. Обязательные члены должны быть предварительно исключены из группового отношения, фиксированные удалены вместе с владельцем, необязательные останутся в БД.
Исключить из группового отношения — разорвать связь между записью-владельцем и записью-членом.
В сетевой модели обеспечивается только поддержание целостности по ссылкам (владелец отношения — член отношения).
Реляционная модель базы данных
Реляционная модель была предложена в 1969 году сотрудником фирмы IBM Е. Ф. Коддом (Or. Е. Р. Соdd), известным исследователем в области баз данных. Впервые основные концепции этой модели были опубликованы в 1970 году.
Набор средств для управления реляционными базами данных называется реляционной системой управления базами данных (РСУБД). Реляционная система управления базами данных может содержать утилиты, приложения, сервисы, библиотеки, средства создания приложений и другие компоненты.
Реляционная база данных представляет собой совокупность двумерных таблиц. Любая таблица реляционной базы данных состоит из строк, называемых записями, и столбцов, называемых полями. Строки таблицы содержат сведения об объектах. Каждый столбец в таблице должен содержать только определенный тип информации. Каждая строка таблицы содержит разнообразную (разного типа) информацию. Все данные, помещенные в одной строке, называют записью, каждый элемент записи — это поле. Таким образом, каждое поле содержит часть информации, находящейся на пересечении соответствующей строки и столбца. В таблице всевозможные значения одного типа в одном столбце называют доменом.
Поле является элементом записи и представляет собой ячейку таблицы. У каждого столбца есть свое неповторимое имя, описывающее тот вид информации, который содержится в нем. Это имя называют «именем поля базы данных»
Каждое поле имеет фиксированную длину, следовательно, и любая запись в таблице имеет фиксированную длину. Каждая запись характеризуется своим уникальным порядковым номером.
Данные в реляционной таблице должны удовлетворять следующим принципам:
1. Каждое значение поля должно быть атомарным, т.е. не расчленяемым на несколько значений;
2. Значения данных домена (в одном и том же столбце) должны принадлежать к одному и тому же типу данных, доступному для использования в данной СУБД;
3. Каждая запись в таблице уникальна, т.е. в таблице не существует двух записей с полностью совпадающим набором значений ее полей;
4. Каждое поле имеет уникальное имя;
5. Последовательность полей в таблице несущественна;
6. Последовательность записей в таблице несущественна.
Существенное отличие реляционной модели от обыкновенного последовательного файла заключается в том, что все столбцы в таблице с точки зрения входа предполагаются эквивалентными. Именно это свойство делает эту модель весьма мощной и делает невозможным отображение ее на память в виде последовательного массива данных.
Поскольку записи в таблице неупорядочены, то необходимо указать поле (или набор нескольких полей) для уникальной идентификации каждой записи.
Первичный ключ — это поле или набор полей, которые однозначно идентифицируют (определяют) запись таблицы
Обычно ключом является поле или совокупность полей фиксированной длины. Каждому значению первичного ключа соответствует одна и только одна запись. Первичный ключ любой таблицы обязан содержать уникальные непустые значения для каждой записи. Если первичный ключ состоит из нескольких полей, он называется составным первичным ключом (рrimагу кеу).
Поле, указывающее на запись в другой таблице, связанную с данной записью, называется внешним ключом (foreign кеу).
Подобное взаимоотношение между таблицами называется связью (ге1ationship). Связь между двумя таблицами устанавливается путем присвоения значений внешнего ключа одной таблицы значениям первичного ключа другой. Таблица, содержащая внешний ключ, называется второстепенной, а таблица, содержащая первичный ключ, определяющий возможные значения внешнего ключа второстепенной таблицы, называется главной.
Типичная реляционная база данных состоит из нескольких связанных таблиц.
Типы связей между объектами
Все информационные объекты предметной области связаны между собой. Соответствия, отношения, возникающие между объектами предметной области, называются связями. Связанные отношениями таблицы взаимодействуют по принципу главная, подчиненная. Возможны следующие отношения между таблицами:
1. Отношение «один – ко – многим» (обозначают 1:М): одной записи из главной таблицы может соответствовать ноль, одна или несколько записей подчинённой таблицы.
2. Отношение «один – к — одному» (обозначают 1:1): одной записи из главной таблицы соответствует только одна запись из подчинённой таблицы.
3. Отношение «многие – ко – многим» (обозначают 1:1): одной записи из главной таблицы может соответствовать ноль, одна или несколько записей подчинённой таблицы и наоборот.
Одним из правил ссылочной целостности (referential integrity) является то, что первичный ключ любой таблицы должен содержать уникальные непустые значения для данной таблицы. Некоторые СУБД могут контролировать уникальность первичных ключей. Если СУБД контролирует уникальность первичных ключей, то при попытке присвоить первичному ключу значение, уже имеющееся в другой записи, СУБД сгенерирует диагностическое сообщение, обычно содержащее словосочетания primary key violation. Это сообщение в дальнейшем может быть передано в приложение, с помощью которого конечный пользователь манипулирует данными.
Если две таблицы связаны соотношением главная-подчиненная, внешний ключ подчинённой таблицы должен содержать только те значения, которые имеются среди значений первичного ключа главной таблицы. Если корректность значений внешних ключей не контролируется СУБД, можно говорить о нарушении ссылочной целостности. Если же СУБД контролирует корректность значений внешних ключей, то при попытке присвоить внешнему ключу значение, отсутствующее среди значений первичных ключей главной таблицы, либо при удалении или модификации записей главной таблицы, приводящих к нарушению ссылочной целостности, СУБД сгенерирует сообщение, о котором говорилось выше.
Вопросы для самоконтроля:
Что такое модель данных?
Для чего строится модель данных?
Укажите достоинства и недостатки иерархической модели данных.
Как организуется физическое размещение данных в БД иерархического типа?
Охарактеризуйте сетевую модель данных.
Охарактеризуйте реляционную модель данных.
Чем отличается реляционная модель данных от предшествующих ей моделей?
Что такое простой ключ и составной ключ?
Перечислите виды связей между объектами? Охарактеризуйте их.
Как проявляется иерархическая подчиненность в связи «один ко многим»?
Лекция 6. Реляционная алгебра
Традиционные операции реляционной алгебры
Специальные операции реляционной алгебры
С точки зрения внешнего представления объектов реального мира модель данных — это основные понятия и способы, используемые при анализе и описании предметной области.
Среди многих попыток представить обработку данных на формальном абстрактном уровне реляционная модель, предложенная Э. Ф. Коддом, стала по существу первой работоспособной моделью данных, поскольку помимо средств описания объектов имела эффективный инструментарий преобразований этих описаний — операции реляционной алгебры.
Реляционная алгебра в том виде, в котором она была определена Э. Ф. Коддом, состоит из двух групп по четыре оператора.
1. Традиционные операции: объединение, пересечение, разность и декартово произведение.
2. Специальные реляционные операции: выборка, проекция, соединение, деление.
Объединение возвращает таблицу, содержащую все записи, которые принадлежат либо одной из двух заданных таблиц, либо им обоим.
Пересечение возвращает таблицу, содержащую все записи, которые принадлежат одновременно двум заданным таблицам.
Разность возвращает таблицу, содержащую все записи, которые принадлежат первому из двух заданных таблиц и не принадлежат второй.
Произведение возвращает таблицу, содержащую все возможные записи, которые являются сочетанием двух записей, принадлежащих соответственно двум заданным таблицам.
Выборка возвращает таблицу, содержащую все записи из заданной таблицы, которые удовлетворяют указанным условиям.
Проекция возвращает таблицу, содержащую все записи заданной таблицы, которые остались в этой таблицы после исключения из неё некоторых атрибутов
Соединение возвращает таблицу, содержащую все возможные записи, которые представляют собой комбинацию атрибутов двух записей, принадлежащих двум заданным таблицам, при условии, что в этих двух комбинированных записях присутствуют одинаковые значения в одном или нескольких общих для исходных таблиц атрибутах (причем эти общие значения в результирующем записи появляются один раз, а не дважды).
Деление для заданных двух унарных таблиц и одной бинарной возвращает таблицу, содержащую все записи из первой унарной таблицы, которые содержатся также в бинарной таблице и соответствуют всем записям во второй унарной таблице.
Результат выполнения любой операции над таблицами также является таблицей, поэтому результат одной операции может использоваться в качестве исходных данных для другой. Другими словами, можно записывать вложенные реляционные выражения, т. е. выражения, в которых операторы сами представлены реляционными выражениями, причем произвольной сложности. Эта особенность называется свойством реляционной замкнутости.
Вопросы для самоконтроля:
Сколько реляционных операций образуют реляционную алгебру?
Перечислите и охарактеризуйте операции реляционной алгебры. Приведите примеры.