Каждый владелец сайта знает, что для правильного функционирования сайта нужны не только файлы с кодом страниц, но и базы данных. Для взаимодействия с базами данных используются системы управления базами данных (СУБД). В данной статье я хочу рассказать о базах данных и СУБД, о том, какие разновидности существуют, и чем они отличаются друг от друга.
База данных
База данных представляет собой определенный набор данных, которые, как правило, связаны объединяющим признаком либо свойством (или несколькими). Эти данные упорядочены, например, по алфавиту. Обилие различных данных, которые могут быть помещены в единую базу, ведет к множеству вариаций того, что может быть записано: личные данные пользователей, записи, даты, заказы и так далее. К примеру, если у вас интернет-магазин, то база данных вашего сайта может содержать прайс-листы, каталог товаров или услуг, отчеты, статистику и информацию о клиентах.
В первую очередь это удобно тем, что информацию можно быстро заносить в базу данных и так же быстро ее извлекать при необходимости. Если на заре развития web-разработки все необходимые данные нужно было прописывать в коде страницы, то теперь такая необходимость отсутствует - нужная информация может быть запрошена из базы данных при помощи скриптов. Специальные алгоритмы хранения и поиска информации, которые используются в базах данных, позволяют находить нужные сведения буквально за доли секунд - а при работе в виртуальном пространстве скорость работы ресурса важна как ничто другое.
Немаловажной является и взаимосвязь информации в базе данных: изменение одной строчки может привести к значительным изменениям других строк. Работать с данными таким образом гораздо проще и быстрее, чем если бы изменения касались только одного места в базе данных.
Однако это не значит, что база данных обязательно должна быть у каждого сайта - к примеру, если у вас сайт-визитка, и никакой новой информации вы на сайте не размещаете, то база данных вам будет попросту не нужна. Самый легкий способ сделать простой сайт - создать .
Система управления базами данных
Как можно догадаться уже из названия, система управления базами данных (или сокращенно СУБД) представляет собой программное обеспечение, которое используется для создания и работы с базами данных. Главная функция СУБД - это управление данными (которые могут быть как во внешней, так и в оперативной памяти). СУБД обязательно поддерживает языки баз данных, а также отвечает за копирование и восстановление данных после каких-либо сбоев.
Что касается классификации баз данных, то тут возможны различные варианты.
К примеру, можно разделить базы по модели данных
: иерархические (имеют древовидную структуру), сетевые (по своей структуре похожи на иерархические), реляционные (используются для управления реляционными базами данных), объектно-ориентированные (используются для объектной модели данных) и объектно-реляционные (некое слияние реляционного и объектно-ориентированного вида баз данных).
Либо, если деление идет по тому, где размещается СУБД , их можно разделить на локальные - вся СУБД размещается на одном компьютере, и распределенные - части системы управления базами данных находятся на нескольких компьютерах.
Файл-серверные, клиент-серверные и встраиваемые - такие названия носят СУБД, если разделить их по способу доступа к базам данных . Файл-серверные СУБД на данный момент уже считаются устаревшими; в основном идет использование клиент-серверных (СУБД, которые располагаются на сервере вместе с самой базой данных) и встраиваемых (не требующих отдельной установки) систем.
Информация, которая хранится в базах данных, не ограничивается только текстовыми или графическими файлами - современные версии СУБД поддерживают также форматы аудио и видеофайлов.
В этой статье я сделаю упор на СУБД, которые используются для хранения информации различных веб-ресурсов.
Зачем же нужны эти СУБД? Помимо основной своей функции - хранения и систематизации огромного количества информации - они позволяют быстро обрабатывать клиентские запросы и выдавать свежую и актуальную информацию.
Это касается и изменений, которые вносите вы - вместо того, чтобы менять информацию в каждом файле сайта, вы можете поменять ее в базе данных, и тогда на каждой странице сразу же будет отображена корректная информация.
Реляционные СУБД и язык SQL
Реляционные и объектно-реляционные СУБД являются одними из самых распространенных систем. Они представляют собой таблицы, у которых каждый столбец (который называется “field” или «поле») упорядочен и имеет определенное уникальное название. Последовательность строк (их называют “records” или «записи») определяется последовательностью ввода информации в таблицу. При этом обрабатывание столбцов и строк может происходить в любом порядке. Таблицы с данными связаны между собой специальными отношениями, благодаря чему с данными из разных таблиц можно работать - к примеру, объединять их - при помощи одного запроса.
Для управления реляционными базами данных применяется особый язык программирования - SQL. Сокращение расшифровывается как “Structured query language”, в переводе на русский «язык структурированных запросов».
Команды, которые используются в SQL, делятся на те, которые манипулируют данными, те, которые определяют данные, и те, которые управляют данными.
Схема работы с базой данных выглядит следующим образом:
MySQL
MySQL является одной из самых популярных и распространенных СУБД, которая используется во многих компаниях (например, Facebook, Wikipedia, Twitter, LinkedIn, Alibaba и других). MySQL представляет собой реляционную СУБД, которая относится к свободному программному обеспечению: она распространяется на условиях GNU Public License. Как правило, эту систему управления базами данных определяют как хорошую, быструю и гибкую систему, рекомендованную к применению в небольших или средних проектах. У MySQL есть множество различных преимуществ. Например, она поддерживает различные типы таблиц: как известные MyISAM и InnoDB, так и более экзотичные HEAP и MERGE; кроме того, количество поддерживаемых типов постоянно растет. MySQL выполняет все команды быстро - возможно, сейчас это самая быстрая СУБД из всех существующих. С этой системой управления базами данных может одновременно работать неограниченное количество пользователей, а число строк в таблицах может быть равно 50 миллионам.
Так как в сравнении с некоторыми другими СУБД MySQL поддерживает меньшее количество возможностей, то и работать с ней значительно проще, чем, к примеру, с PostgreSQL, о которой будет рассказано ниже.
Первая версия MySQL вышла в далеком 1995 году, и с тех пор состоялось несколько последующих релизов, каждый из которых нес в себе значительные изменения.
Для работы с MySQL используется не только текстовый, но и графический режим. Это возможно благодаря приложению phpMyAdmin: для работы в приложении вам даже не нужно будет знать SQL-команды, а администрировать свою базу данных можно прямо через браузер.
В целом можно отметить, что MySQL - это выбор тех, кому необходима СУБД для проекта небольшого или среднего размера, быстрая и удобная в работе и без сложностей с администрированием.
PostgreSQL
Эта свободно распространяемая система управления базами данных относится к объектно-реляционному типу СУБД. Как и в случае с MySQL, работа с PostgreSQL основывается на языке SQL, однако, в отличие от MySQL, PostgreSQL поддерживает стандарт SQL-2011. Эта СУБД не имеет ограничений ни по максимальному размеру базы данных, ни по максимуму записей или индексов в таблице.
Если говорить о преимуществах PostgreSQL, то, безусловно, это надежность транзакций и репликаций, возможность наследования и легкая расширяемость. PostgreSQL поддерживает различные расширения и варианты языков программирования, такие как PL/Perl, PL/Python и PL/Java. Также есть возможность загружать C-совместимые модули.
Многие отмечают, что в отличие от MySQL данная СУБД имеет хорошую и подробную документацию, которая дает ответы практически на все вопросы.
О том, что это более масштабная, чем MySQL, СУБД, говорит и тот факт, что PostgreSQL периодически сравнивают с такой мощной системой управления данных, как Oracle.
Все это позволяет говорить о PostgreSQL как об одной из самых продвинутых СУБД на данный момент.
SQLite
На данный момент это одна из самых компактных СУБД; также она является встраиваемой и реляционной. SQLite позволяет хранить все данные в одном файле и, благодаря своему небольшому объему, отличается завидным быстродействием. SQLite значительно отличается от MySQL и PostgreSQL своей структурой: движок и интерфейс этой СУБД находятся в одной библиотеке - и именно это позволяет выполнять все запросы очень быстро. Другие СУБД (MySQL, PostgreSQL, Oracle и т.д.) используют парадигму клиент-сервер, когда взаимодействие происходит через сетевой протокол.
Из недостатков можно отметить отсутствие системы пользователей и возможности увеличения производительности.
SQLite можно посоветовать к использованию в проектах, где нужно иметь возможность быстро перенести приложение, и нет необходимости в масштабируемости.
Oracle
Эта СУБД относится к объектно-реляционному типу. Название произошло от названия разработавшей эту систему фирмы Oracle. Наравне с SQL СУБД использует процедурное расширение под названием PL/SQL, а также язык Java.
Oracle - это система, отличающаяся стабильностью уже не один десяток лет, поэтому ее выбирают крупные корпорации, для которых важна надежность восстановления после сбоев, отлаженная процедура бэкапа, возможность масштабирования и другие ценные возможности. К тому же эта СУБД обеспечивает отличную безопасность и эффектную защиту данных.
В отличие от других СУБД, стоимость покупки и использования Oracle достаточно высока, и именно это зачастую является значимым препятствием к ее использованию в небольших фирмах. Вероятно, именно это также является причиной того, что в рейтинге СУБД на 2016 год в России Oracle находится лишь на 6-м месте.
MongoDB
Эта СУБД отличается тем, что она предназначена для хранения иерархических структур данных, и поэтому ее называют документоориентированной (она представляет собой документное хранилище без использования таблиц или схем). MongoDB имеет открытый исходный код.
Используя идентификатор, вы можете производить быстрые операции над объектом; эта СУБД хорошо показывает себя и при сложных взаимодействиях. В первую очередь речь идет о быстродействии - в некоторых случаях приложение, написанное на MongoDB, будет работать быстрее, чем такое же приложение, использующее SQL, т.к. MongoDB относится к классу СУБД NoSQL и вместо SQL пользуется объектным языком запросов, который значительно легче SQL.
Однако этот язык имеет и свои ограничения, а поэтому MongoDB следует использовать в случаях, когда нет необходимости в сложных и нетривиальных выборках.
Вместо заключения
Выбор СУБД - это важный момент при создании своего ресурса. Отталкивайтесь от своих задач и возможностей, пробуйте и экспериментируйте, чтобы найти именно тот вариант, который будет наиболее подходящим.
Построение реляционных баз данных
Основы построения реляционных баз данных
Описание реляционных данных
В процессе построения реляционной базы данных должны быть решены несколько задач. Во-первых, необходимо описать структуру базы данных для СУБД. Для этого разработчик использует язык описания данных или какой-либо эквивалентный способ описания структуры (например, графическое отображение). Затем база данных записывается на тот или иной физический носитель и заполняется данными. В этом разделе мы рассмотрим каждую из этих задач, но сначала познакомимся с реляционной терминологией.
Обзор терминологии
Как указывалось в главе 5, отношение - это таблица, обладающая определенными свойствами.
Записи в отношении могут иметь только одиночные значения; множественные значения не допускаются. Следовательно, на пересечении строки и столбца находится только одно значение.
Все записи в одном столбце имеют один и тот же тип. Например, один столбец может содержать имена покупателей, а другой - их даты рождения. Каждый столбец имеет уникальное имя, и порядок следования столбцов несуществен. Столбцы отношения носят название атрибутов. Каждый атрибут имеет свой домел, который представляет собой физическое и логическое описание множества допустимых значений.
3. В отношении не может быть двух одинаковых строк, и порядок следования строк несуществен (рис. 8.1). Строки отношения называются также кортежами.
Рисунок 8.1 являет собой пример, или отдельный экземпляр, реляционной структуры, содержащей сведения о пациенте клиники. Обобщенный формат, PATIENT (Name , Birth Date , Gender , AccountNumber , Physician ) - это структура отношения; именно ее большинство людей имеют в виду под термином отношение. (Вспомните из главы 5, что подчеркиванием выделяется атрибут, являющийся ключом отношения.) Если мы добавим в структуру отношения ограничение на возможные значения данных, мы получим реляционную схему (relational schema). Все эти термины приведены в табл. 8.1.
Недоразумения относительно термина «ключ»
Термин ключ зачастую является источником недоразумений, так как он имеет различные значения на стадиях проектирования и реализации. В процессе проектирования под ключом понимается один или несколько столбцов, однозначно определяющих строку отношения. Как мы знаем из главы 5, каждое отношение имеет хотя бы один ключ, поскольку каждая строка является уникальной; в предельном случае ключ представляет собой комбинацию всех столбцов отношения. Обычно ключ состоит из одного-двух столбцов.
На стадии реализации термин ключ используется в другом значении. В большинстве реляционных СУБД ключом называется столбец, на базе которого СУБД формирует индекс и другие структуры данных. Это делается для того, чтобы обеспечить быстрый доступ к значениям из данного столбца. Эти ключи не обязаны быть уникальными, и зачастую они действительно таковыми не являются. Они создаются только для повышения быстродействия. (Информацию о таких структурах данных вы найдете в приложении А.)
Рассмотрим, например, отношение ЗАКАЗ (НомерЗаказа, ДатаЗаказа, НомерКли-ента, Количество). С точки зрения проектирования, ключом этого отношения является НомерЗаказа, так как выделение жирным шрифтом означает, что данный атрибут однозначно определяет строку отношения. С точки зрения реализации, ключом может быть любой из четырех столбцов данного отношения. Это может быть, например, атрибут ДатаЗаказа. В таком случае СУБД создаст структуру данных, обеспечивающую быстрый доступ к данным из отношения ЗАКАЗ по значению даты заказа. Скорее всего, конкретному значению атрибута ДатаЗаказа будет соответствовать много строк. В данном смысле определение атрибута в качестве ключа не говорит ничего о его уникальности.
Иногда, чтобы различать два значения слова ключ, употребляются термины логический ключ (logical key) и физический ключ (physical key). Логический ключ - это уникальный идентификатор, а физический ключ - это столбец, для которого с целью увеличения быстродействия создан индекс или другая структура данных.
Индексы
Поскольку физический ключ обычно является индексом, некоторые оставляют за термином ключ значение логического ключа, а за термином индекс - значение физического ключа. В данной книге мы именно так и будем поступать: термин ключ мы будем использовать в значении «логический ключ», а термин индекс - в значении «физический ключ».
В пользу создания индексов есть три соображения. Одно из них состоит в том, чтобы обеспечить ускоренный доступ к строкам по значению индексируемого атрибута. Другое заключается в упрощении сортировки строк по этому атрибуту. Например, в отношении ЗАКАЗ в качестве ключа может быть определен атрибут ДатаЗаказа, в результате чего отчеты, в которых заказы отсортированы по дате, будут генерироваться быстрее.
Третья цель построения индексов - обеспечение уникальности. Индексы не обязаны быть уникальными, но когда разработчик хочет, чтобы какой-то столбец был уникальным, СУБД создает для этого столбца индекс. В большинстве реляционных СУБД столбец или группу столбцов можно сделать уникальными, если при определении столбца в таблице указать ключевое слово UNIQUE .
Реализация реляционной базы данных
И этой книге для описания структуры базы данных мы используем реляционную модель. Поэтому от проектирования базы данных мы можем непосредственно переходить к ее реализации. Нам нет нужды как-либо преобразовывать структуру па стадии реализации: все, что требуется сделать, - это описать существующую реляционную структуру для СУБД.
При реализации баз данных с использованием СУБД, основанных не на реляционной модели, дело обстоит иначе. Например, реализуя базу данных на основе модели DL/I, мы должны преобразовать реляционную структуру в иерархическую, а затем описать для СУБД преобразованную структуру.
Описание структуры базы данных для СУБД
Есть несколько способов, с помощью которых структура базы данных описывается для СУБД. Эти способы зависят от того, какая конкретно СУБД используется. 13 некоторых продуктах создается текстовый файл, который описывает структуру базы данных. Язык, используемый для определения такой структуры, иногда называется языком определения данных (data definition language, DDL). В текстовом DDL-файле перечислены названия таблиц базы данных, указаны названия столбцов этих таблиц и описано их содержимое, определены индексы, а также описаны другие структуры (ограничения, меры безопасности). В листинге 8.1 с помощью типичного языка определения данных описана простая реляционная база данных для гипотетической СУБД. Более реалистичные примеры с использованием стандарта под названием SQL приведены в главах 12 и 13.
Некоторые СУБД не требуют, чтобы структура базы данных была определена с помощью DDL в текстовом формате. Наиболее распространенная альтернатива - это графический способ задания структуры базы данных. Например, в Access 2002 разработчику дается графическая структура в виде списка, в соответствующих местах которой нужно ввести имена таблиц и столбцов. Пример этого мы видели в главе 2 (см. рис. 2.2).
Вообще говоря, графические средства описания данных распространены в СУБД, предназначенных для работы на персональных компьютерах. На серверах и больших ЭВМ применяются как графические, так и текстовые средства. Например, в Oracle и SQL Server для определения данных могут применяться оба способа. На рис. 8 .2 представлена общая схема процесса описания данных для СУБД.
При любом способе определения структуры данных разработчик должен дать название каждой таблице, определить столбцы для этой таблицы и описать физический формат данных в каждом столбце (скажем, TEXT 10). Кроме того, в зависимости от возможностей используемой СУБД, разработчик может указать ограничения, которые должны реализовываться СУБД. Значения столбцов могут определяться, например, как NOT NULL (не пустой) или UNIQUE (уникальный). Некоторые продукты позволяют также устанавливать ограничения на возможные значения (атрибут Часть может принимать значения, меньшие 10 000, а атрибут Цвет может принимать одно из значений ["Красный"/Зеленый"/Синий"]). Наконец, могут быть введены ограничения целостности по внешнему ключу. Приведем пример такого ограничения: «Значение атрибута НомерОтдела в таблице СОТРУДНИК должно быть равно значению атрибута НомерОтдела в таблице ОТДЕЛ».
Во многих СУБД разработчик может также устанавливать пароли и использовать другие средства контроля и безопасности. Как будет показано в главе 11, существует множество различных стратегий обеспечения безопасности. В одних стратегиях объектами контроля являются структуры данных (например, таблица защищается паролем), в других - пользователи (обладатель пароля X может читать и обновлять таблицы Т1 и Т2).
Распределение пространства на физических носителях
Кроме определения структуры базы данных, разработчик должен выделить место для базы данных на физическом носителе. И вновь конкретные действия зависят от того, какая именно СУБД используется. В случае персональной базы данных псе, что требуется сделать, - это присвоить базе данных каталог на диске и дать ей имя. После этого СУБД автоматически выделит пространство для хранения данных.
Другие СУБД, в особенности предназначенные для серверов и больших ЭВМ, требуют больших усилий. Чтобы повысить быстродействие и улучшить контроль, необходимо тщательно спроектировать распределение информации в базе данных по дискам и каналам. Например, в зависимости от специфики обработки приложений, может оказаться, что определенные таблицы лучше размещать на одном и том же диске. И наоборот, может быть важно, чтобы определенные таблицы не находились на одном и том же диске.
Рассмотрим, например, объект-заказ, скомпонованный из таблиц ЗАКАЗ, СТР0КА_ ЗАКАЗА и ТОВАР. Предположим, что при обработке заказа приложение считывает одну строку из таблицы ЗАКАЗ, несколько строк из таблицы СТР0КА_ЗАКАЗА и по одной строке из таблицы ТОВАР для каждой строки из таблицы СТР0КА_ЗАКАЗА. Далее, строки из таблицы СТР0КА_ЗАКАЗА, относящиеся к одному и тому же заказу, обычно сгруппированы вместе, а строки в таблице ТОВАР не сгруппированы никак. Эту ситуацию иллюстрирует рис. 8.3.
Теперь представим, что организация параллельно обрабатывает множество заказов и что у нее есть два диска: один большого объема и быстродействующий, а другой - меньшего объема и более медленный. Разработчик должен определить наилучшее место для хранения данных. Возможно, производительность улучшится, если таблица ТОВАР будет храниться на большом диске с быстрым доступом, а таблицы СТРОКА_ЗАКАЗА и ЗАКАЗ - на диске меньшего размера и быстродействия. А может быть, производительность будет выше, если поместить данные из таблиц ЗАКАЗ и СТРОКА_ЗАКАЗА за предыдущие месяцы на более медленный диск, а за текущий месяц - на более быстрый.
Мы не можем ответить на эти вопросы здесь, поскольку ответ зависит от объема данных, характеристик СУБД и операционной системы, размера и быстродействия дисков и каналов, а также от требований приложений, использующих эту базу данных. Смысл состоит в том, что все эти факторы необходимо принимать во внимание при выделении пространства для базы данных на физическом носителе.
Кроме местоположения и объема пространства для данных пользователя, разработчику, возможно, потребуется также указать, должно ли это пространство увеличиваться по мере необходимости, и если да, то на какую величину. Как правило, величина такого приращения указывается либо в виде фиксированного значения, либо в виде процентов от первоначального объема занимаемого пространства.
При создании базы данных разработчику понадобится выделить файловое пространство для журналов базы данных. О ведении журналов вы узнаете в главах 11-13; на данном этапе вам просто следует знать, что СУБД ведет журнал изменений в базе данных, который потом, в случае необходимости, можно использовать для восстановления базы. Файловое пространство для журналов выделяется на этапе создания базы данных.
Составление плана обслуживания базы данных
План обслуживания (maintenance plan) базы данных - это расписание процедур, которые необходимо выполнять на регулярной основе. Эти процедуры включают в себя резервное копирование базы данных, сброс содержимого журнала базы данных в архивные файлы, проверка на наличие нарушений ссылочной целостности, оптимизация дискового пространства для данных пользователя и индексов и т. д. К этим вопросам мы также обратимся в главе 11, но имейте в виду, что план обслуживания базы данных должен составляться в процессе ее создания или вскоре после него.
Заполнение базы данных информацией
Когда база данных описана и для ее хранения выделено пространство на физическом носителе, можно начинать заполнение базы данных информацией. То, каким путем это делается, зависит от требования приложений и возможностей СУБД. В лучшем случае все данные уже находятся в формате, воспринимаемом компьютером, а в СУБД имеются возможности и средства, позволяющие упростить импорт данных с магнитных носителей. В худшем случае все данные должны вводиться вручную через клавиатуру с помощью прикладных программ, созданных разработчиками «с нуля». Большинство ситуаций, где необходимо конвертирование данных, находятся в промежутке между этими двумя крайними случаями.
Когда данные введены, необходимо проверить их корректность. Такая проверка утомительна и требует больших трудозатрат, однако она весьма важна. Зачастую, особенно в больших базах данных, есть смысл в написании специальных программ для проверки данных. Преимущества от использования этих программ вполне окупят время и деньги, затраченные командой разработчиков на их создание. Такие программы занимаются тем, что подсчитывают количество строк в различных категориях, вычисляют контрольные суммы, выполняют проверки допустимости значений данных и другие процедуры контроля.
Манипулирование реляционными данными
Мы обсудили проектирование реляционных баз данных и способы, при помощи которых структура базы данных описывается для СУБД. До сих пор, говоря об операциях с отношениями, мы рассуждали в обобщенной и интуитивной манере. Такая манера хороша, пока речь идет о проекте, но для реализации приложений нам нужен четкий и непротиворечивый язык, выражающий логику обработки. Такие языки носят название языков манипулирования данпьши (data manipulation languages, DML).
На сегодняшний день предложено четыре стратегии манипулирования реляционными данными. Первая из стратегий, реляционная алгебра (relational algebra), определяет операторы, действующие на отношения (они подобны операторам высшей алгебры +, - и т. д.). Эти операторы позволяют манипулировать отношениями для достижения желаемого результата. Но реляционная алгебра трудна в использовании, отчасти потому, что она является процедурной. Это значит, что при использовании реляционной алгебры мы должны знать не только то, что мы делаем, но и то, как это делается.
Реляционная алгебра не используется в коммерческих системах обработки баз данных. Хотя ни одна коммерчески успешная СУБД не включает в себя инструментарий реляционной алгебры, мы будем обсуждать ее здесь, поскольку это поможет яснее представить себе манипулирование реляционными данными и заложит основу для изучения SQL.
Реляционное исчисление (relational calculus) - вторая стратегия манипулирования реляционными данными. Реляционное исчисление не является процедурным; оно представляет собой язык, выражающий то, что мы хотим сделать, без указания на то, как этого достичь. Вспомните переменную интегрирования в интегральном исчислении: эта переменная принимает значения из того диапазона, по которому происходит интегрирование. В реляционном исчислении есть подобная переменная. В кортежио-реляционном исчислении областью значений этой переменной являются кортежи отношения, а в доменно-реляционном исчислении - значения домена. В основе реляционного исчисления лежит область математики, называемая исчислением предикатов.
Если вы не собираетесь становиться теоретиком реляционной технологии, вам, скорее всего, не понадобится изучать реляционное исчисление. Оно никогда не используется в коммерческих системах обработки баз данных, и в его изучении для наших целей нет необходимости. Таким образом, мы не будем обсуждать его в этой книге.
Хотя реляционное исчисление трудно для понимания и использования, его непроцедурный характер является преимуществом. Поэтому разработчики СУБД начали поиск других непроцедурных стратегий, который привел к появлению третьей и четвертой категорий языков манипулирования реляционными данными.
Языки, ориентированные на преобразования (transform-oriented languages), - это класс непроцедурных языков, которые преобразуют входные данные, имеющие вид отношений, в результат, представляющий собой одно отношение. В этих языках имеются простые в использовании структуры, позволяющие указать действия, которые необходимо совершить с предоставленными данными. SQUARE, SEQUEL и SQL - это примеры языков, ориентированных на преобразования. Язык SQL будет подробно изучаться нами в главах 9, 12 и 13.
Четвертая категория языков манипулирования реляционными данными - это графические языки. К этой категории относятся запрос по образцу (Query-by-Example) и запрос из формы (Query-by-Form). В числе продуктов, поддерживающих эту категорию, можно упомянуть Approach (фирмы Lotus) и Access. Пользователю выдается графическое представление одного отношения или более. Представление может иметь вид формы для ввода данных, электронной таблицы или какой-либо другой структуры. СУБД преобразует представление в соответствующее отношение и формирует запросы (скорее всего, на SQL) от лица пользователя. После этого пользователи инициируют выполнение операторов DML, по они об этом не знают. Четыре категории языков манипулирования реляционными данными:
реляционная алгебра;
реляционное исчисление;
языки, ориентированные на преобразования (например, SQL);
запрос по образцу, запрос из формы.
Интерфейсы языков манипулирования данными
В этом разделе мы рассмотрим четыре вида интерфейсов, с помощью которых осуществляется манипулирование информацией в базе данных.
Манипулирование данными посредством форм
В большинстве реляционных СУБД имеются средства для создания форм. Некоторые формы генерируются автоматически при определении таблицы, другие должны создаваться разработчиком. Помощь в этом процессе может оказать интеллектуальный ассистент, присутствующий, например, в Access. Форма может иметь вид таблицы (электронной таблицы), в которой одновременно показываются несколько строк отношения. Есть и другой вид форм, где каждая строка отношения представляется отдельно. На рис. 8.4 и 8.5 приведены примеры обоих типов форм для таблицы PATIENT с рис. 8.1. Большинство продуктов обеспечивают некоторую гибкость в обработке форм и отчетов. Например, строки для обработки могут выбираться по значениям столбцов и могут быть отсортированы. Таблица па рис. 8.4 отсортирована по значению поля AccountNumber.
Многие формы, генерируемые по умолчанию, содержат в себе данные только из одного отношения. Если нужно получить данные из двух или более отношений, тогда, как правило, нужно создавать специальные формы с помощью средств СУБД. Такие средства позволяют создавать как многотабличные, так и многострочные формы. Поскольку использование этих средств сильно зависит от конкретной СУБД, мы не будем рассматривать их далее.
Интерфейс языка запросов и обновлений
Второй тип интерфейса к базе данных - это язык запросов и обновлений (query/ update language), или просто язык запросов (query language). (Хотя большинство такого рода языков позволяют выполнять как запрос, так и обновление данных, их чаще всего называют языками запросов.) В этом случае пользователь вводит команды, которые указывают, какие действия необходимо произвести над базой данных. СУБД расшифровывает эти команды и выполняет предписанные действия. Рисунок 8.6 показывает, какие программы участвуют в обработке запроса.
Важнейшим из всех языков запросов является SQL. Чтобы дать вам представление о языках запросов, рассмотрим следующий SQL-оператор, который обрабатывает отношение PATIENT , показанное на рис. 8.1:
SELECT Name. DateOfBirth FROM PATIENT
WHERE Physician = "Levy"
Этот оператор извлекает из отношения PATIENT все строки, в которых атрибут Physician имеет значение " Levy ". Значения атрибутов Name и DateOf Birth из этих строк он затем помещает во вторую таблицу.
Хранимые процедуры
Со временем пользователи и разработчики баз данных обнаружили, что некоторые последовательности команд SQL приходится выполнять регулярно. Единственное, что при этом меняется, - это значения, указываемые в предложении WHERE . Например, при ежемесячном начислении платежей выполняются одни и те же SQL-операторы, но с различной датой закрытия. Чтобы учесть эту потребность, производители СУБД ввели так называемые хранимые процедуры (stored procedures). Такая процедура представляет собой набор SQL-операторов, который хранится в файле и может быть запущен на выполнение одной командой. Параметры, указываемые в предложении WHERE и т. д., могут передаваться при вызове процедуры. Примером может служить следующее:
DO BILLING STORED_PROCEDURE FOR BILLDATE = "9/1/2000"
Эта строка запускает хранимую процедуру под названием BILLING со значением параметра BILLDATE , равным "9/1/2000".
По мере накопления разработчиками опыта выявилась одна проблема. SQL создавался как подъязык данных, и при этом не делалось попыток наделить его всеми элементами полноценного языка программирования. Однако некоторые из этих элементов были необходимы для написания хранимых процедур, и производители СУБД создали расширенные версии SQL, включив в них дополнительные возможности. Один такой язык, PL/SQL, был разработан для Oracle, а еще один, под названием TRANSACT-SQL, - для SQL Server. Более подробно об этих языках вы узнаете из глав 12 и 13.
Специальный тип хранимой процедуры - триггер (trigger) - вызывается СУБД при выполнении заданного условия. Например, в приложении, обрабатывающем заказы, разработчик должен создать триггер, который запускается в тех случаях, когда количество товара на складе оказывается ниже заданного предела (то есть пора заказывать товар у оптового поставщика). Более подробно о хранимых процедурах вы узнаете из глав 12 и 13.
Интерфейс прикладных программ
Четвертый тип интерфейса доступа к данным - это доступ через прикладные программы, написанные на таких языках программирования, как COBOL, BASIC, Perl, Pascal и С++. Кроме того, некоторые прикладные программы пишутся на встроенных в используемые СУБД языках. Из таких языков программирования наибольшей известностью пользуется dBASE.
Есть два стиля интерфейса между прикладными программами и СУБД. Первый из них характеризуется тем, что прикладные программы вызывают подпрограммы из библиотеки функций, поставляемой в комплекте с СУБД. Например, чтобы считать строку из таблицы, прикладная программа вызывает функцию чтения СУБД и передает ей параметры, которые указывают нужную таблицу, требуемые столбцы, критерии выбора строки и т. п.
В некоторых случаях вместо вызовов функций используется объектно-ориентированный синтаксис. В приведенном ниже коде Access объектный указатель db устанавливается на открытую в данный момент базу данных, а объектный указатель rs ссылается на строки таблицы PATIENT ;
set db = currentdbC)
set rs = db.OpenRecordsetCPATIENT")
С помощью последнего указателя можно обращаться к свойствам откры того набора записей и запускать его методы. Например, с помощью свойства rs . AllowDeletions можно определить, могут ли быть удалены записи из набора записей PATIENT . Метод MoveFirst перемещает курсор на первую строку.
Второй, более старый тип интерфейса используется иногда в СУБД, предназначенных для больших ЭВМ и серверов. Здесь производителем СУБД определен набор высокоуровневых команд доступа к данным. Эти команды, которые относятся к обработке базы данных и не являются частью какого-либо стандартного языка, встраиваются в код прикладной программы.
Прикладная программа со встроенными командами передается на предварительный компилятор, входящий в комплект СУБД. Он транслирует операторы доступа к данным в корректные вызовы функций и определяет области данных, которые будут совместно использоваться прикладными программами и СУБД. Предварительный компилятор также вставляет в программу код, поддерживающий доступ к этим областям данных. Обработанная таким образом программа передается на языковой компилятор. На рис. 8 .7 показано взаимодействие программ в этом процессе.
Введение
Глава1. Основы баз данных
1.1.Классификация баз данных
1.3Модели описания баз данных
1.4. Основы работы настольных СУБД
1.5.Требования и стандарты, предъявляемые к базам данных
Глава 2. Работа с базой данных Microsoft Access
2.1. Основы работы настольной СУБД Microsoft Access
2.2. Работа с базой данных Microsoft Access
Заключение
Список использованной литературы
Введение
Потоки информации, циркулирующие в мире, который нас окружает, огромны. Во
времени они имеют тенденцию к увеличению. Поэтому в любой организации, как
большой, так и маленькой, возникает проблема такой организации управления
данными, которая обеспечила бы наиболее эффективную работу. Некоторые
организации используют для этого шкафы с папками, но большинство предпочитают
компьютеризированные способы – базы данных, позволяющие эффективно хранить,
структурировать и систематизировать большие объемы данных. И уже сегодня без баз
данных невозможно представить работу большинства финансовых, промышленных,
торговых и прочих организаций. Не будь баз данных, они бы просто захлебнулись в
информационной лавине.
Существует много веских причин перевода существующей информации на компьютерную основу. Сейчас стоимость хранения информации в файлах ЭВМ дешевле, чем на бумаге. Базы данных позволяют хранить, структурировать информацию и извлекать
оптимальным для пользователя образом. Данная тема актуальна в настоящее время, т.к. использование клиент/серверных технологий позволяют сберечь значительные средства, а главное и время для получения необходимой информации, а также упрощают доступ и ведение, поскольку они основываются на комплексной обработке данных и централизации их хранения. Кроме того ЭВМ позволяет хранить любые форматы данных, текст, чертежи, данные в рукописной форме, фотографии, записи голоса и т.д.
Для использования столь огромных объемов хранимой информации, помимо развития
системных устройств, средств передачи данных, памяти, необходимы средства
обеспечения диалога человек - ЭВМ, которые позволяют пользователю вводить
или принимать решения на основании хранимых данных. Для обеспечения этих функций
созданы специализированные средства – системы управления базами данных (СУБД).
Целью данной работы является раскрыть понятие базы данных и системы управления базами данных, а также рассмотреть на конкретном примере работу настольной СУБД.
1.1.Классификация баз данных
База данных – это информационная модель предметной области, совокупность взаимосвязанных, хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений. Данные (файлы) хранятся во внешней памяти и используются в качестве входной информации для решения задач.
СУБД - это программа, с помощью которой реализуется централизованное управление данными, хранимыми в базе, доступ к ним, поддержка их в актуальном состоянии.
Системы управления базами данных можно классифицировать по способу установления связей между данными, характеру выполняемых ими функций, сфере применения, числу поддерживаемых моделей данных, характеру используемого языка общения с базой данных и другим параметрам.
Классификация СУБД:
· по выполняемым функциям СУБД подразделяются на операционные и информационные;
· по сфере применения СУБД подразделяются на универсальные и проблемно-ориентированные;
· по используемому языку общения СУБД подразделяются на замкнутые, имеющие собственные самостоятельные языки общения пользователей с базами данных, и открытые, в которых для общения с базой данных используется язык программирования, расширенный операторами языка манипулирования данными;
· по числу поддерживаемых уровней моделей данных СУБД подразделяются на одно-, двух-, трехуровневые системы;
· по способу установления связей между данными различают реляционные, иерархические и сетевые базы данных;
· по способу организации хранения данных и выполнения функций обработки базы данных подразделяются на централизованные и распределенные.
Системы централизованных баз данных с сетевым доступом предполагают две основные архитектуры – файл-сервер или клиент-сервер.
Архитектура файл-сервер. Предполагает выделение одной из машин сети в качестве центральной (главный сервер файлов), где хранится совместно используемая централизованная база данных. Все другие машины исполняют роль рабочих станций. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится их обработка. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает.
Архитектура клиент-сервер. Эта модель взаимодействия компьютеров в сети для современных СУБД фактически стала стандартом. Каждый из подключенных к сети и составляющих эту архитектуру компьютеров играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент имеет возможность пользоваться ими. Помимо хранения централизованной базы данных сервер базы данных обеспечивает выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запроса SQL.
Сервер базы данных представляет собой СУБД, параллельно обрабатывающую запросы, поступившие со всех рабочих станций. Как правило, клиент и сервер территориально отделены друг от друга, и в этом случае они образуют систему распределенной обработки данных.
1.2. Функциональные возможности СУБД
Характеристиками СУБД являются:
· производительность;
· обеспечение целостности данных на уровне баз данных;
· обеспечение безопасности данных;
· возможность работы в многопользовательских средах;
· возможность импорта и экспорта данных;
· обеспечение доступа к данным с помощью языка SQL;
· возможность составления запросов;
· наличие инструментальных средств разработки прикладных программ.
Производительность СУБД оценивается:
· временем выполнения запросов;
· скоростью поиска информации;
· временем импортирования баз данных из других форматов;
· скоростью выполнения операций (таких как обновление, вставка, удаление);
· временем генерации отчета и другими показателями.
· Безопасность данных достигается:
· шифрованием прикладных программ;
· шифрованием данных;
· защитой данных паролем;
· ограничением доступа к базе данных (к таблице, к словарю и т.д.).
Обеспечение целостности данных подразумевает наличие средств, позволяющих удостовериться, что информация в базе данных всегда остается корректной и полной. Целостность данных должна обеспечиваться независимо от того, каким образом данные заносятся в память (в интерактивном режиме, посредством импорта или с помощью специальной программы). Используемые в настоящее время СУБД обладают средствами обеспечения целостности данных и надежной безопасности.
Система управления базами данных управляет данными во внешней памяти, обеспечивает надежное хранение данных и поддержку соответствующих языков базы данных. Важной функцией СУБД является функция управления буферами оперативной памяти. Обычно СУБД работают с базами данных больших размеров, часто превышающими размеры оперативной памяти ЭВМ. В развитых СУБД поддерживается свой набор буферов оперативной памяти с собственной дисциплиной их замены.
Наибольшее распространение в настоящее время получили системы управления базами данных Microsoft Access и Oracle.
Этапами работы в СУБД являются:
· создание структуры базы данных, т.е. определение перечня полей, из которых состоит каждая запись таблицы, типов и размеров полей (числовой, текстовый, логический и т.д.), определение ключевых полей для обеспечения необходимых связей между данными и таблицами;
· ввод и редактирование данных в таблицах баз данных с помощью представляемой по умолчанию стандартной формы в виде таблицы и с помощью экранных форм, специально создаваемых пользователем;
· обработка данных, содержащихся в таблицах, на основе запросов и на основе программы;
· вывод информации из ЭВМ с использованием отчетов и без использования отчетов.
Реализуются названные этапы работы с помощью различных команд.
Централизованная база данных обеспечивает простоту управления, улучшенное использование данных на местах при выполнении дистанционных запросов, более высокую степень одновременности обработки, меньшие затраты на обработку.
Распределенная база данных предполагает хранение и выполнение функций управления данными в нескольких узлах и передачу данных между этими узлами в процессе выполнения запросов. В такой базе данных не только различные ее таблицы могут храниться на разных компьютерах, но и разные фрагменты одной таблицы. При этом для пользователя не имеет значения как организовано хранение данных, он работает с такой базой, как с централизованной.
1.3.Модели описания баз данных
Известны три типа моделей описания баз данных – иерархическая, сетевая и реляционная, основное различие между которыми состоит в характере описания взаимосвязей и взаимодействия между объектами и атрибутами базы данных.
Иерархическая модель предполагает использование для описания базы данных древовидных структур, состоящих из определенного числа уровней. «Дерево» представляет собой иерархию элементов, называемых узлами. Под элементами понимается список, совокупность, набор атрибутов, элементов, описывающих объекты.
База данных – это совокупность структурированных и взаимосвязанных данных, относящихся к определенной предметной области.
Для создания, хранения, обработки и коллективного использования информации применяются специальные программные системы, называемые системами управления базами данных (СУБД).
К основным функциям СУБД относятся следующие:
· физическое размещение в памяти данных и их описаний;
· поддержка баз данных в актуальном состоянии;
· механизмы поиска запрашиваемых данных;
· доступ к данным при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
· способы обеспечения защиты данных от некорректных обновлений и/или несанкционированного доступа.
Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры.
Тщательное проектирование базы данных – первый и очень важный шаг создания базы. Он позволяет избежать затрат, связанных с внесением исправлений в структуру хранящихся данных. Проектирование базы данных начинается с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). На этапе проектирования выявляются объекты информации и их характеристики, определяются виды данных, требующие регулярного обновления, и способы представления информации на экране и в отчетах, формулируются вопросы, на которые необходимо регулярно отвечать при поиске данных. Это помогает конкретизировать требования к хранимой информации. В любой момент можно изменить структуру хранящейся в базе информации, подкорректировав структуру таблиц и, соответственно, форм и отчетов. За проектирование и поддержку базы данных отвечает администратор базы данных (АБД).
СУБД использует следующие модели и описания:
· инфологическую;
· даталогическую;
· физическую.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ.
Первоначально создается обобщенное неформальное описание создаваемой базы данных. Это описание называют инфологической моделью данных, и оно выполняется с использованием естественного языка, блок-схем, математических формул, таблиц, графиков и других средств. Инфологическая модель отражает предметную область, для которой проектируется база данных, и полностью независима от физических параметров среды хранения данных. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты). Инфологическая модель не должна изменяться до тех пор, пока изменения в реальном мире не повлекут за собой изменения предметной области и, следовательно, изменения в модели.
Описание, создаваемое разработчиками базы данных по инфологической модели данных, называют даталогической моделью данных. Конечным результатом даталогического проектирования является описание логической структуры базы данных на ЯОД – языке описания данных конкретной СУБД. При создании даталогической модели данных обеспечивается однозначное соответствие между конструкциями языка описания данных и графическими обозначениями информационных единиц и связей между ними.
В основе каждой СУБД лежит концепция модели данных, то есть некоторой абстракции представления данных. Изначально были успешными две конкурирующие модели – иерархическая и сетевая. Иерархическая БД состоит из упорядоченного набора деревьев. Корпорация IBM разработала и внедрила язык описания данных DL/I (Data Language One), который моделировал данные в иерархической форме (представление данных в форме деревьев). Эта модель была разработана совместно с промышленными предприятиями и предназначалась для хранения и поддержки данных, которые иерархически связаны между собой, например, сметы материалов и списки деталей. Типичным представителем иерархической СУБД является СУБД IMS (Information Management System) компании IBM, первая версия которой появилась в 1968 г.
На рис.8.1 показан пример схемы иерархической БД. Тип записи ФАКУЛЬТЕТ является предком (родительской или исходной записью) для типов записей КАФЕДРЫ и ДЕКАНАТ, а записи КАФЕДРЫ и ДЕКАНАТ – потомки (дочерние или порожденные записи) для записи ФАКУЛЬТЕТ.
Все экземпляры определенного типа порожденной записи, относящиеся к одному экземпляру исходной записи, называются близнецами. Иерархическая модель реализует отношение между исходной и дочерними записями по схеме один-ко-многим., то есть одной родительской записи может соответствовать любое число дочерних. В иерархической базе данных существует единственный иерархический путь доступа к любой записи, начиная с корня дерева, т.е. порядок обхода дерева – сверху-вниз, слева-направо. По сути иерархическая модель – ориентированный граф.
Рис. 8.1. Схема иерархической модели базы данных
В терминологии IMS вместо термина "запись" использовался термин "сегмент", а под термином "запись базы данных" понималось все дерево сегментов. В 1970 году группа CODASYL, которая разрабатывала стандарты для языка COBOL, создала модель под названием DBTG (Data Base Task Group, группа задач базы данных). Модель DBTG была готова к представлению как иерархических, так и сетевых данных. Однако эта модель была очень сложной, поэтому не имела большого успеха.
Типичным представителем систем, основанных на сетевой модели данных, является СУБД IDMS (Integrated Database Management System), разработанная компанией Cullinet Software, Inc. Сетевой подход к организации данных является расширением иерархического подхода. Как и в иерархической модели, связи ведут от родительской записи к дочерней, но на этот раз поддерживается множественное наследование. В сетевой модели допускается несколько исходных записей для одной порожденной записи наряду с возможностью наличия записей без исходной записи (рис.8.2). Другими словами, в сетевой модели любая запись может участвовать в нескольких отношениях предок-потомок. Сетевая модель – неориентированный граф.
Рис. 8.2. Схема сетевой модели базы данных
Большинство применяемых сегодня баз данных основаны на реляционной модели. Основная идея реляционной модели – представить произвольную структуру данных в виде двумерных таблиц. Наиболее распространенной в настоящее время настольной реляционной базой данных является MS Access, пример которой рассматривается в разделе 6.3.3.
Реляционная модель впервые была предложена Э.Ф. Коддом (E.F. Codd) в 1970 году. Понятие модели данных, введенное Коддом, впоследствии развил Кристофер Дейт. Согласно Дейту, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части. Данные хранятся в таблицах. Столбцы таблиц называются полями, а строки – записями. В каждом поле может храниться информация только одного типа. Запросы предназначены для манипулирования данными, содержащимися в базе данных.
Кодд определил правила реляционной модели, которые получили название "12 правил Кодда". Позже Кодд добавил "нулевое" правило.
1. Реляционная СУБД должна быть способна полностью управлять базой данных, используя связи между данными.
2. Информационное правило: вся информация в реляционной БД, включая имена таблиц и столбцов, должна определяться строго как значения таблиц.
3. Гарантированный доступ: любое значение БД должно быть гарантированно доступным через комбинацию имени таблицы, первичный ключ и имя столбца.
4. Поддержка нулевого значения: СУБД должна уметь работать с нулевыми (пустыми) значениями. Нулевое значение – это неизвестное, независимое, неприменимое значение, в отличие от значений по умолчанию и обычных значений.
5. Активный, оперативный реляционный каталог – описание БД и ее содержимое – должны быть определены на логическом уровне через таблицы, к которым можно применять запросы, используя DML (Data Manipulation Language – язык манипулирования данными).
6. Исчерпывающее подмножество языка данных: по крайней мере, один из поддерживаемых языков должен иметь четко определенный синтаксис и быть самодостаточным. Он должен поддерживать определение данных и манипулирование ими, правила целостности, авторизацию и транзакции.
7. Правило обновления представлений: все представления, теоретически обновляемые, могут быть обновлены через систему.
8. Вставка, обновление и удаление: СУБД поддерживает не только запрос данных, но и вставку, обновление и удаление.
9. Физическая независимость данных: логика программ-приложений остается прежней при изменении физических методов доступа к данным и структур хранения.
10. Логическая независимость данных: логика программ-приложений остается прежней, в пределах разумного, при изменении структур таблиц.
11. Независимость целостности: язык БД должен быть способен определять ограничения целостности. Они должны быть доступны из оперативного каталога, и не должно быть способа их обойти.
12. Независимость распределения: перенос базы данных с одного компьютера на другой компьютер не должен оказывать влияния на запросы программ-приложений. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.
13. Согласованность языков всех уровней: низкоуровневый язык доступа к данным не должен игнорировать правила безопасности и целостности, поддерживаемые языком более высокого уровня.
Предложив реляционную модель данных, Э.Ф. Кодд создал и инструмент для удобной работы с отношениями – реляционную алгебру – формальную систему манипулирования отношениями, основными операциями которой являются проекция, соединение, пересечение и объединение.
Реляционное исчисление – это еще одна формальная система, которая манипулирует отношениями. Реляционное исчисление основано на логике первого порядка. Так же как и выражения реляционной алгебры, формулы реляционного исчисления определяются над отношениями реляционных баз данных, и результатом вычисления также является отношение.
Реляционная алгебра и реляционное исчисление имеют одинаковую выражающую мощность; т. е. все запросы, которые можно сформулировать с помощью реляционной алгебры, могут быть также сформулированы с помощью реляционного исчисления и наоборот. Первым это доказал Э. Ф. Кодд в 1972 году. Это доказательство основано на алгоритме, по которому произвольное выражение реляционного исчисления может быть сокращено до семантически эквивалентного выражения реляционной алгебры. Алгоритм носит название "алгоритм редукции Кодда".
Реляционные базы данных имеют следующие специфические особенности.
· Для каждого поля таблицы базы данных определен тип данных, таким образом нельзя в одно поле разных записей вводить данные разных типов.
· СУБД позволяют не только вводить данные в таблицы, но и контролировать правильность вводимых данных. Имеются в виду не только ограничения по типу данных, но и контроль допустимых значений, количество вводимых знаков и т.п. СУБД не позволит сохранить в записи те данные, которые не удовлетворяют заданным правилам.
· Таблицы баз данных могут включать в себя количество записей, исчисляемое сотнями тысяч, и при этом СУБД обеспечивает удобные способы извлечения нужной информации из этого множества записей.
· Все данные хранятся, независимо от их структуры и содержания, в одном файле, и доступ к этим данным осуществляется постранично, не превышая ограничений на ресурсы компьютера.
· Можно устанавливать связи между таблицами и затем при помощи запросов совместно использовать данные разных таблиц. Данные, полученные в результате запроса, представляются также в виде таблицы.
· Запрос на выборку может быть обращен к одной или нескольким таблицам одновременно. Данные в выборке являются динамическими, т. е. при повторном запуске запроса по измененным данным, выборка изменяется.
· Благодаря установке взаимосвязей между отдельными таблицами удается избежать ненужного дублирования данных, сэкономить память компьютера, а также увеличить скорость обработки информации.
· Большинство баз данных может поддерживать одновременную работу с базой данных нескольких пользователей, при этом все пользователи гарантированно будут работать с актуальными данными.
· По сравнению с другими прикладными пакетами в базах данных имеется развитая система защиты от несанкционированного доступа, которая предоставляет, помимо парольной защиты файла, возможность каждому пользователю или группе пользователей видеть и изменять только те объекты, к которым пользователи имеют право доступа.
При проектировании реляционной базы данных большое внимание уделяется процессу нормализации таблиц. Целью нормализации является создание такого проекта базы данных, где будет исключена избыточность информации, т. е. каждый квант информации будет сохраняться лишь в одном месте. Основное назначение нормализации – исключение возможной противоречивости хранимых данных и экономия памяти. Пренебрежение нормализацией делает структуру базы данных запутанной, а саму базу – ненадежной в работе.
Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функциональные и многозначные.
Поле В таблицы функционально зависит от поля А той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля А обязательно существует только одно из различных значений поля В. Отметим, что здесь допускается, что поля А и В могут быть составными.
Поле В находится в полной функциональной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А.
Поле А многозначно определяет поле В той же таблицы, если для каждого значения поля А существует определенное множество соответствующих значений В.
Процесс нормализации представляет собой последовательное преобразование исходной БД к нормализованной базе данных путем поэтапного приведения таблиц к нормальным формам (НФ). При этом каждая следующая НФ обязательно включает в себя предыдущую, что позволяет разбить процесс на этапы и производить его однократно, не возвращаясь к предыдущим этапам. Всего в реляционной теории насчитывается 6 нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ) и пятая нормальная форма (5НФ).
По существу, таблица находится в 2НФ, если она находится в 1НФ и удовлетворяет, кроме того, некоторым дополнительным условиям. Таблица находится в 3НФ, если она находится в 2НФ и, помимо этого, удовлетворяет другим дополнительным условиям и т.д.
Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто.
Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
Таблица находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля.
Кодд и Бойс обосновали и предложили более строгое определение для 3НФ, которое учитывает, что в таблице может быть несколько ключей. Таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только если любая функциональная зависимость между ее полями сводится к полной функциональной зависимости от возможного ключа.
В следующих нормальных формах (4НФ и 5НФ) учитываются не только функциональные, но и многозначные зависимости между полями таблицы.
В настоящее время практически каждый производитель СУБД предлагает собственный программный продукт автоматизированного проектирования. Это Oracle Designer (Oracle), Power Desinger (Sybase) и другие. Демонстрационные версии данных программных продуктов можно загрузить с соответствующих сайтов (www.oracle.com, www.sybase.com). Кроме того, для автоматизированного проектирования представлены решения фирм, не производящих СУБД. Наиболее распространенными являются программные продукты фирмы AllFusion – AllFusion ERwin Data Modeler и AllFusion Process Modeler (ранее – BPwin) (см. www.interface.ru).
Реляционные языки обеспечивают типовые операции по обработке реляционных таблиц, позволяют формулировать логические условия, используемые в операциях выборки, проверку целостности (непротиворечивости) данных взаимосвязанных таблиц. Они оперируют с данными как со множествами, применяя к ним основные операции теории множеств. На входе реляционного оператора – множество записей одной или нескольких реляционных таблиц, на выходе – множество записей новой реляционной таблицы. Реляционные языки имеют различный уровень процедурности – содержание и последовательность перехода от входных данных к выходным.
Выделяют следующие разновидности языков реляционной алгебры:
· dBASe-подобные языки приближены к языкам структурного программирования. Эти языки обеспечивают создание интерфейса пользователя и типовые операции обработки данных;
· графические реляционные языки, ориентированные на конечных пользователей;
· SQL-подобные языки запросов, реализованные в большинстве многопользовательских и распределенных систем управления базами данных.
dBASe-подобные языки используют базы данных dBASe, Paradox, FoxPro, Clipper, Rbase и др.
Типичным представителем графического реляционного языка является язык QBE (Query By Example), реализованный в среде электронных таблиц, в различных базах данных, например, в MS Access, в пакете Microsoft Query. Этот язык относится к языкам манипулирования данными и имеет простейшие синтаксические конструкции, легко осваиваемые пользователями-непрограммистами.
SQL (Structured Query Language) применяется при работе с реляционными базами данных в современных СУБД (ORACLE, dBASE IY, dBASE Y, Paradox, Access и др.). Для отдельных СУБД синтаксис версий языка SQL может различаться.
Язык SQL стал стандартом языков запросов для работы с реляционными базами данных архитектуры "файл-сервер" и "клиент-сервер" и для управления распределенными базами данных. Это реляционно полный язык, предназначенный для работы с базами данных, создания запросов на выборку данных, для выполнения вычислений, для обеспечения целостности баз данных.
База данных -- организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных, характеризующая актуальное состояние некоторой предметной области и используемая для удовлетворения информационных потребностей пользователей.
База данных -- совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных.
База данных -- совокупность взаимосвязанных данных, совместно хранимых в одном или нескольких компьютерных файлах.
Существует множество других определений, отражающих скорее субъективное мнение тех или иных авторов о том, что означает этот термин в их понимании, однако общепризнанная единая формулировка отсутствует. Наиболее часто используются следующие отличительные признаки: База данных хранится и обрабатывается в вычислительной системе. Таким образом, любые внекомпьютерные хранилища информации (архивы, библиотеки, картотеки и т. п.) базами данных не являются.
Данные в базе данных логически структурированы (систематизированы) с целью обеспечения возможности их эффективного поиска и обработки в вычислительной системе.
Структурированность подразумевает явное выделение составных частей (элементов), связей между ними, а также типизацию элементов и связей, при которой с типом элемента (связи) соотносится определённая семантика и допустимые операции.
Из перечисленных признаков только первый является строгим, а другие допускает различные трактовки и различные степени оценки. Можно лишь установить некоторую степень соответствия требованиям к БД.
Многие специалисты указывают на распространённую ошибку, состоящую в некорректном использовании термина база данных вместо термина система управления базами данных. Эти понятия, следовательно, необходимо различать.
Базы данных необходимы для хранения и фильтрации информации, для её обработки и обмена. В целом, спектр применения достаточно широкий. По всему миру люди используют БД, начиная от простого пользователя-любителя, заканчивая крупнейшими мировыми корпорациями.
База данных - это хранилище для большого количества систематизированных данных, с которыми можно производить определённые действия. Под действиями понимается добавление, удаление, изменение, копирование, упорядочивание и прочее.
Все данные в БД можно представить в виде записей или объектов.
Для успешной работы с БД необходимы какие-то программные средства, при помощи которых можно было бы создавать и управлять БД. Для этого существуют Системы Управления Базами Данных (СУБД).
СУБД - совокупность языковых и программных средств, обеспечивающих создание, использование и ведение БД.
Существует два вида СУБД: локальные и сетевые.
Локальные - это СУБД, работающие на одном компьютере. К таким относятся dBase, FoxPro, Microsoft Access, Paradox и т.д.
Сетевые - это СУБД, позволяющие нескольким компьютерам использовать одну и ту же БД с помощью технологии клиент-сервер. Примером таких СУБД являются InterBase, Oracle, Microsoft SQL Server и т.д.Поскольку мы разбираем общие понятия, то расскажу немного о взаимосвязи данных.
Существует 4 типа взаимосвязи данных:
1) Один к одному
2) Один ко многим
3) Много к одному
4) Много ко многим
Вид взаимосвязи один к одному означает, что каждая запись одного объекта БД будет указывать на единственную запись другого объекта.
Один ко многим означает, что одной записи объекта БД будет соответствовать несколько записей других объектов.
Много к одному означает, что нескольким записям объектов БД будет соответствовать одна запись другого объекта.
Много ко многим устанавливается между двумя типами объектов БД.
Характеристика баз данных
База данных - это реализованная с помощью компьютера информационная структура (модель), отражающая состояние объектов и их отношения.
Следует учесть, что это определение не является единственно возможным. Информатика в отношении определений чаще всего не похожа на математику с ее полной однозначностью. Если подойти к понятию “база данных” с чисто пользовательской точки зрения, то возникает другое определение: база данных - совокупность хранимых операционных данных некоторого предприятия. Все дело в том, какой аспект доминирует в рассмотрении; в данной главе первое из определений более уместно.
Опыт использования баз данных позволяет выделить общий набор их рабочих характеристик:
* полнота - чем полнее база данных, тем вероятнее, что она содержит нужную информацию (однако, не должно быть избыточной информации);
* правильная организация - чем лучше структурирована база данных, тем легче в ней найти необходимые сведения;
* актуальность - любая база данных может быть точной и полной, если она постоянно обновляется, т.е. необходимо, чтобы база данных в каждый момент времени полностью соответствовала состоянию отображаемого ею объекта;
* удобство для использования - база данных должна быть проста и удобна в использовании и иметь развитые методы доступа к любой части информации.
Соответственно возможностям организации реляционных, иерархических и сетевых информационых структур, существуют и аналогичные виды баз данных.
Основные типы баз данных
1) Иерархические
2) Сетевые
3) Реляционные
Иерархические базы данных
Иерархические БД применялись в начале 60-х годов. Они построены в виде обычного дерева. Данные делятся на 2 категории: главные и подчинённые. Таким образом, один тип объекта является главным, а остальные, находящиеся на более низких ступенях иерархии, - подчинёнными.БД, организованные по такому принципу, удобно использовать в тех случаячх, когда информамция упорядочена соответствующим образом.
Сетевые базы данных
Сетевые БД начали применятся практически одновременно с иерархическими. В этих БД любой объект может быть как главным, так и подчинённым.
В использовании довольно сложно реализовать представление данных в таком виде, поэтому от этого типа тоже отказались.
Реляционные базы данных
Именно реляционные БД используются в повседневной жизни. (от англ. relation - отношение). Такой тип БД представляется собой несколько взаимосвязанных таблиц прямоугольной формы. В которых собственное есть поля, ключи, записи, аторибуты и прочее и прочее.
