Системы управления базами данных

Базовое отношение – это именованное  отношение, которое не является производным (т.е. является автономным).

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

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

Представление – именованное производное  отношение. Представления виртуальны – они представляются в системе  исключительно через определение  в терминах других именованных отношений.

Снимки (snapshot) – это именованные  производные отношения, в отличие  от представлений являющиеся реальными, а не виртуальными

Результат запроса – неименованное  производное отношение, служащее результатом  некоторого определенного запроса. База данных не обеспечивает постоянного  существования для результатов  запросов (чтобы сохранить результат  запроса, его нужно присвоить  некоторому именованному отношению).

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

Хранимое отношение – отношение, которое поддерживается в физической памяти “непосредственным” образом. Хранимое отношение не всегда совпадает  с базовым отношением. Набор хранимых отношений должен быть таким, чтобы  все базовые отношения, а значит, и все выражаемые отношения можно  было произвести от него; но при этом не требуется, чтобы все хранимые отношения были базовыми отношениями, и не требуется, чтобы все базовые  отношения были хранимыми.

4. 1.3. Распределенные базы данных

Одним из основных дополнительных вопросов современной теории реляционных  БД является понятие распределенных БД.

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

          1. Простота использования системы.

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

3. Высокая степень эффективности.

Примером распределенной СУБД является Oracle, MS SQL.

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

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

При реализации распределенной БД должны выполняться следующие требования:

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

2. Все узлы распределенной БД должны рассматриваться системой в общем случае как равноправные (в конкретной реализации узлы могут быть несколько неравноправны). Зависимость всей системы от какого-либо ее узла может привести к тому, что он станет наиболее уязвимым ее местом и, кроме того, в этом случае не представляется возможным реализовать условие автономности.

3. Распределенная БД должна обеспечивать высокую надежность и доступность. Надежность рассматриваемой системы заключается в том, что система исправна и будет работать в заданный момент (это достигается за счет того, что система продолжает свою работу – иногда и с ограниченными возможностями -, даже если имеет место сбой отдельного узла). Доступность системы определяется исправностью системы в течение длительного промежутка времени и возможностью обработки данных в реальном масштабе времени.

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

5. Распределенная БД не должна быть зависима от аппаратного обеспечения, операционной системы, вычислительной сети и от самой СУБД.

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

Высокая эффективность функционирования распределенной СУБД достигается за счет:

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

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

3. Дублирование отношений в нескольких узлах с поддержкой согласованности копий и поддержка мгновенных снимков состояния БД в соответствии с заданным запросом.

 

 

 

 

 

5.Выбор средств проектирования и СУБД

При проектировании базы данных Горисполкома после описания предметной области необходимо выбрать метод построения инфологической модели (ER-модели) и СУБД, в которой будет реализован проект. Для построения ER-модели была выбрана программа MySQL Workbench. Я выбрал эту программу, потому что она позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда упрощает разработку базы данных и автоматизирует множество трудоемких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных. Наиболее важными для нас являются следующие возможности данного CASE-средства:

• Возможность редактирования данных в таблице в визуальном режиме.
• Удобный редактор SQL запросов, позволяющий сразу же отправлять их серверу и получать ответ в виде таблицы.
• Reverse Engineering — восстановление структуры таблиц из уже существующей на сервере БД (связи восстанавливаются в InnoDB, при использовании MyISAM — связи необходимо устанавливать вручную).
• Наглядный и функциональный механизм установки связей между таблицами, в том числе «многие ко многим» с созданием таблицы связей.

Существует большое число СУБД. По функциональным возможностям СУБД бывают настольные (FoxPro, MS Access, Paradox) и  корпоративные (Oracle, MS SQL Server, MySQL). Сравнивая  настольные и корпоративные СУБД, можно отметить следующее: настольные СУБД просты в использовании, стоимость их эксплуатации дешевле; корпоративные СУБД имеют возможности администрирования, работы в Интернете, поддерживают большой объем данных и быстродейственны. Для построения самой базы данных мной было выбрано MySQL.

MySQL является решением для малых  и средних приложений. Входит  в состав серверов WAMP, AppServ, LAMP и в портативные сборки серверов Денвер, XAMPP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов  таблиц: пользователи могут выбрать  как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

MySQL портирована на большое количество платформ: AIX, BSDi, FreeBSD, HP-UX, Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003, WinCE, Windows Vista и Windows 7. Существует также порт MySQL к OpenVMS. Важно отметить, что на официальном сайте СУБД для свободной загрузки предоставляются не только исходные коды, но и откомпилированные и оптимизированные под конкретные операционные системы готовые исполняемые модули СУБД MySQL. MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, PureBasic, Python, Ruby, Smalltalk, Компонентный Паскаль и Tcl библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

 

 

 

 

Основные  возможности MySQL:

• Многопоточность. Поддержка нескольких одновременных запросов.
• Оптимизация связей с присоединением многих данных за один проход.
• Записи фиксированной и переменной длины.
• ODBC драйвер в комплекте с исходником
• Гибкая система привилегий и паролей.
• До 16 ключей в таблице. Каждый ключ может иметь до 15 полей.
• Поддержка ключевых полей и специальных полей в операторе CREATE.
• Поддержка чисел длинной от 1 до 4 байт (ints, float, double, fixed), строк переменной длины и меток времени.
• Интерфейс с языками C и perl.
• Основанная на потоках, быстрая система памяти.
• Утилита проверки и ремонта таблицы ( isamchk).
• Все данные хранятся в формате ISO8859_1.
• Все операции работы со строками не обращают внимания на регистр символов в обрабатываемых строках.
• Псевдонимы применимы как к таблицам, так и к отдельным колонкам в таблице.
• Все поля имеют значение по умолчанию. INSERT можно использовать на любом подмножестве полей.
• Легкость управления таблицей, включая добавление и удаление ключей и полей.

 

 

 

 

 

 

6.Построение инфологической (концептуальной) модели предметной области

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

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

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

Описание объектов ПО и связей между  ними оказывает наибольшее влияние  на проектирование структуры базы данных. Представим описание объектов и связей между ними в виде Базовой ER-модели: