Для специальности 5В073200 «Стандартизация, сертификация и метрология»



страница3/10
Дата06.06.2016
Размер1.01 Mb.
ТипЛекция
1   2   3   4   5   6   7   8   9   10

Нормализация


Основная статья: Нормальная форма

При проектировании реляционных баз данных обычно выполняется так называемая нормализация.


Модели «сущность-связь»


Основная статья: ER-модель данных

Модель «сущность-связь» (англ. Entity-Relationship model), или ER-модель, предложенная П. Ченом[1] в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма, либо с использованием других графических нотаций (Crow's Foot, Information Engineering и др.).

Основные преимущества ER-моделей:


  • наглядность;

  • модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;

  • ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

  • объекты (сущности);

  • атрибуты объектов;

  • связи между объектами.

Сущность — объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:



  • типом связи (1:1, 1:N, N:М);

  • классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности — обязательный, иначе — необязательный.

Семантические модели


Семантическая модель (концептуальная модель, инфологическая модель) – модель предметной области, предназначенная для представления семантики предметной области на самом высоком уровне абстракции. Это означает, что устранена или минимизирована необходимость использовать понятия «низкого уровня», связанные со спецификой физического представления и хранения данных.

Дейт К. Дж. Введение в системы баз данных. — 8-е изд. — М.: «Вильямс», 2006:

Семантическое моделирование стало предметом интенсивных исследований с конца 1970-х годов. Основным побудительным мотивом подобных исследований (т.е. проблемой, которую пытались разрешить исследователи) был следующий факт. Дело в том, что системы баз данных обычно обладают весьма ограниченными сведениями о смысле хранящихся в них данных. Чаще всего они позволяют лишь манипулировать данными определенных простых типов и определяют некоторые простейшие ограничения целостности, наложенные на эти данные. Любая более сложная интерпретация возлагается на пользователя. Однако было бы замечательно, если бы системы могли обладать немного более широким объемом сведений и несколько интеллектуальнее отвечать на запросы пользователя, а также поддерживать более сложные (т.е. более высокоуровневые) интерфейсы пользователя.
[…]
Идеи семантического моделирования могут быть полезны как средство проектирования базы данных даже при отсутствии их непосредственной поддержки в СУБД.

Наиболее известным представителем класса семантических моделей является модель «сущность-связь» (ER-модель).

Лекция 5. Физическая организация баз данных и СУБД.

Администрирование баз данных процесс сука сложный и опасный. Мало того, что DBA часто сходят с ума от груза ответственности, так они это делают и с пользователями, доводя их до исступления эмоций словами "блин, где же у меня бэкапы". Истории известны летальные исходы. DBA как правило разворачивают СУБД, обеспечивают ее целостность и работоспособность. Даже в случае прямого попадания метеорита в сервер БД. Берегут систему от сбоев и лечат поврежденные базы данных. Резервное копирование - непремнно обязательная часть администрирования БД. Также DBA должен добавлять и удалять пользователей, назначать им права и тд. Проверять состояние индексов и ссылочную целостность.

К языковым средствам СУБД можно отнести язык SQL, хранимые процедуры, триггеры. Современные СУБД позволяют использовать встроенные функции в языке запросов. Хранимые процедуры позволяют существенно расширить возможности языка sql, организуя процедурную обработку данных на сервере по алгоритму пользователя. Триггеры - своеобразные защелки, обработчики событий, возникающих в базе данных. (Например, можно сделать триггер BEFORE_INSERT, который будет делать что то перед вставкой новой записи в таблицу)

Structured Query Language — язык структурированных запросов — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. Вопреки существующим заблуждениям, SQL является информационно-логическим языком, а не языком программирования. SQL основывается на реляционной алгебре. Язык SQL делится на четыре части:



  • операторы определения данных (англ. Data Definition Language, DDL)

  • операторы манипуляции данными (англ. Data Manipulation Language, DML)

  • операторы определения доступа к данным (англ. Data Control Language, DCL)

  • операторы управления транзакциями (англ. Transaction Control Language, TCL)

Преимущества
Независимость от конкретной СУБД
Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую. Существуют системы, разработчики которых изначально закладывались на применение по меньшей мере нескольких СУБД (например: система электронного документооборота Documentum может работать как с Oracle, так и с Microsoft SQL Server и IBM DB2). Естественно, что при применении некоторых специфичных для реализации возможностей такой переносимости добиться уже очень трудно.
Наличие стандартов
Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка. Правда, стоит обратить внимание, что сам по себе стандарт местами чересчур формализован и раздут в размерах, например, Core-часть стандарта SQL:2003 представляет собой более 1300 страниц текста.
Декларативность
С помощью SQL программист описывает только то, какие данные нужно извлечь или модифицировать. То, каким образом это сделать, решает СУБД непосредственно при обработке SQL-запроса. Однако не стоит думать, что это полностью универсальный принцип — программист описывает набор данных для выборки или модификации, однако ему при этом полезно представлять, как СУБД будет разбирать текст его запроса. Особенно критичны такие моменты становятся при работе с большими базами данных и со сложными запросами — чем сложнее сконструирован запрос, тем больше он допускает вариантов написания, различных по скорости выполнения, но одинаковых по итоговому набору данных. Недостатки
Несоответствие реляционной модели данных
Создатель реляционной модели данных Эдгар Кодд, Кристофер Дейт и их сторонники указывают на то, что SQL не является истинно реляционным языком. В частности они указывают на следующие проблемы SQL[3]:

  • Повторяющиеся строки

  • Неопределённые значения (nulls)

  • Явное указание порядка колонок слева направо

  • Колонки без имени и дублирующиеся имена колонок

  • Отсутствие поддержки свойства «=»

  • Использование указателей

  • Высокая избыточность

Сложность


Хотя SQL и задумывался, как средство работы конечного пользователя, в конце концов он стал настолько сложным, что превратился в инструмент программиста.
Отступления от стандартов
Несмотря на наличие международного стандарта ANSI SQL-92, многие компании, занимающиеся разработкой СУБД (например, Oracle, Sybase, Microsoft, MySQL AB), вносят изменения в язык SQL, применяемый в разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом появляются специфичные для каждой конкретной СУБД диалекты языка SQL.
Сложность работы с иерархическими структурами
Ранее SQL не предлагал стандартного способа манипуляции древовидными структурами. Некоторые поставщики СУБД предлагали свои решения. Например, Oracle использует выражение CONNECT BY. В настоящее время в качестве стандарта принята рекурсивная конструкция WITH.

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


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

Лекция 6. Архитектуры доступа к БД. Системные аспекты.

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

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

К числу функциональных компонент СУБД относятся:

§ управление средой хранения данных;

§ методы доступа к данным;

§ поддержка уровней представления данных (концептуального, внутреннего и внешнего);

§ механизмы управления транзакциями;

§ поддержка функций администратора системы;

§ интерактивные пользовательские интерфейсы;

§ интерфейсы прикладного программирования.

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

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

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

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

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

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

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

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

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

Наиболее распространенным вариантом распределенной архитектуры еще с начала 90-х годов стала архитектура «клиент-сервер». При этом предусматривается выделение одного из функциональных компонентов системы, называемого сервером, для оказания определенных услуг по запросам других компонентов, называемых клиентами. Роли клиента и сервера в рассматриваемой архитектурной модели являются относительными, так как они ассоциируются с конкретным набором услуг. Функциональный компонент, являющийся клиентом относительно одного набора услуг, может быть вместе с тем сервером, оказывающим другие услуги.

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

Концепция «клиент-сервер» может также использоваться в среде сосредоточенной архитектуры.

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

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

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

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

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







Лекция 7. Языки запросов. Язык SQL.

Язык SQL – Structured Query Language – был разработан в 1974 г. в ходе работы над System R. В период становления технологий баз данных SQL был не единственным и, возможно, не самым лучшим языком запросов  реляционных баз данных, но со временем стал стандартом в этой области. Такая "победа" языка SQL обусловлена, во-первых, ориентацией на него первых и ведущих производителей коммерческих СУБД, во-вторых,  тем, что уже в своей версии для System R он был достаточно хорошо развит не только как язык запросов, но и обеспечивал в полном объеме описание и управление данными. Коммерческие продукты далеко не сразу обеспечили свойства исходной версии SQL в полном объеме.

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

Разработкой стандартов языка SQL занимается Американский национальный комитет по стандартизации (ANSI) при поддержке Международной Организации  Стандартов (ISO). Стандарты SQL принимались в 1987 г. (уточнен в 1989 г.), в 1992 г и в 1999 г. Однако даже ведущие СУБД сертифицированы только на уровень "Entry" стандарта SQL-92. В реальных СУБД применяются "диалекты" SQL. Процесс стандартизации динамичный и трудный – то, что сегодня является диалектом одной СУБД, завтра может стать стандартом. Язык SQL состоит из трех подмножеств:



  • языка определения данных;

  • языка манипулирования данными;

  • языка управления данными.

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



Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   10


База данных защищена авторским правом ©uverenniy.ru 2019
обратиться к администрации

    Главная страница