Предметной области

ВВЕДЕНИЕ В БАЗЫ ДАННЫХ

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

База данных – это поименованная совокупность данных, относящихся к определенной предметной области.

Система управления базами данных – это комплекс программных и языковых средств, необходимых для создания, обработки баз данных и поддержания их в актуальном состоянии.

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

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

Класс объектов – совокупность объектов, обладающих одинаковым набором свойств.

Свойство (атрибут) – определенная часть информации о некотором объекте. Хранится в виде столбца (поля) таблицы.

Связь (отношение) – способ, которым связана информация о разных объектах.

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

1. Системный анализ и словесное описание информационных объектов предметной области.

2. Проектирование инфологической модели предметной области – частично формализованное описание объектов предметной области в терминах некой инфологической, например, ER-модели.

3. Даталогическое (или логическое) проектирование БД, то есть описание БД в терминах принятой даталогической модели.

4. Физическое проектирование БД, то есть выбор способа размещения БД на внешних носителях.

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

Инфологическая модель должна выражать информацию в виде, не зависящем от используемой системы управления базами данных (далее – СУБД). Обычно эта модель отражает описание объектов, их свойства и взаимосвязи в виде схем. В настоящий момент наиболее широкое распространение получила модель Чена (Chen), которая называется «сущность-связь» или ER-модель (Entity Relationship). В ее основе лежат следующие базовые понятия.

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

Между сущностями могут быть установлены связи. По множественности связи делятся на три типа: один-к-одному (один экземпляр одной сущности связан только с одним экземпляром другой сущности), один-ко-многим (один экземпляр одной сущности связан с несколькими экземплярами другой сущности), многие-ко-многим (один экземпляр одной сущности связан с несколькими экземплярами другой сущности и наоборот). Связь любого типа может быть обязательной, если в данной связи должен участвовать каждый экземпляр, и необязательной. Связь может быть обязательной с одной стороны и необязательной с другой.

Для реализации проекта в конкретной СУБД следует разработать даталогическую модель. На настоящий момент для этой цели используется реляционная модель данных. Основной структурой данных в модели является отношение, именно поэтому модель получила название реляционной (от англ. «relation» - «отношение»).

Существует алгоритм преобразования ER-модели в реляционную модель данных:

1. Каждой сущности ставится в соответствие отношение реляционной модели данных.

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

3. Первичный ключ сущности становится ключевым полем соответствующего отношения.

4. В каждое отношение, соответствующее подчиненной сущности, добавляется атрибут основной сущности, и этот атрибут становится внешним ключом.

5. Для определения необязательного типа связи у атрибута, соответствующего внешнему ключу, устанавливается необязательность данного атрибута. При обязательном типе связи устанавливается его обязательность.

6. Если в ER-модели присутствуют связи «многие-ко-многим», то для перехода к реляционной модели данных (где такие связи не поддерживаются) вводится дополнительное связующее отношение. Оно связано с каждым исходным связью «один-ко-многим», а его атрибутами служат первичные ключи связываемых отношений.

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

ОСНОВНЫЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

Основным структурным компонентом базы данных является таблица. При определении состава таблиц следует руководствоваться правилом: в каждой таблице должны храниться данные только об одном классе объектов. Например, в одной таблице нельзя хранить анкетные данные студента и фамилии преподавателей, которым он сдавал экзамены, т.к. это свойства разных классов объектов.

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

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

Связь типа “один-к-одному”: При этом типе связи каждой записи в одной таблице соответствует не более одной записи в другой таблице. Этот вид связи встречается довольно редко. В основном в тех случаях, когда часть информации об объекте либо редко используется, либо является конфиденциальной. (Такая информация хранится в отдельной таблице, которая защищена от несанкционированного доступа).

Связь типа “один-ко-многим”: При таком типе связи каждой записи в одной таблице соответствует несколько записей в связанной таблице. Этот наиболее распространенный тип связей. Для его реализации используются две таблицы. Одна из них представляет сторону " один", другая - сторону " много".

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

СУБД MS ACCESS

Первая версия MS Access была создана в 1993 г. фирмой Microsoft. MS Access – это функционально полная реляционная СУБД, работающая в среде Windows. Access позволяет создавать сложные базы данных, определяя структуру таблиц, связи между ними. Access обладает совершенной системой создания запросов, отчетов и форм любой сложности. В Access, как любом приложении Windows, можно использовать все возможности обмена данными между приложениями (DDE и OLE), что позволяет включить в базу данных графическую и (или) звуковую информацию.

В Access база данных включает в себя все объекты, связанные с хранимыми данными (таблицы, формы, отчёты, запросы, макросы, модули). Все объекты Access хранятся в одном файле с расширением.mdb. В таблицах хранятся данные, которые можно просматривать, редактировать, добавлять. Используя формы, можно выводить данные на экран в удобном виде, просматривать и изменять их. Запросы позволяют быстро выбирать необходимую информацию из таблиц. С помощью отчётов можно создавать различные виды документов для вывода на печать. Макросы и модули позволяют автоматизировать работу с базой данных.

Запуск Access осуществляется щелчком мыши по Пуск\Microsoft Access. После запуска на экране появится рабочий экран программы MS Access, в верхней строке которого расположено Главное меню, а под ним панель инструментов. Она содержит кнопки, дублирующие действия команд главного меню. С помощью команды Вид\Панели инструментов можно самостоятельно определить, которые из них будут отображены на экране.

В средней части расположено начальное окно Microsoft Access, состоящее из двух полей. Верхнее поле предлагает создать новую БД и содержит кнопки для выбора способа ее создания: с помощью конструктора (Новая база данных) или с помощью Мастера баз данных (Запуск мастера). Нижнее поле этого окна предлагает открыть уже созданную ранее БД.

После нажатия кнопки Новая база данных Access запрашивает имя для файла, в котором будет храниться база данных и открывает окно новой базы данных.

Нажав кнопку Запуск Мастера, Access приглашает создать базу данных, используя некоторые стандартные темы приложений из своей библиотеки. Эти приложения включают в себя весь необходимый набор объектов: таблицы, запросы, формы, отчеты, макросы, модули. Из предложенных примеров можно выбрать подходящий и на его основе создать свою БД. После этого пользователю остается только ввести в таблицы нужные данные.

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

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

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

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

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