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

Руководство по проектированию баз данных.

1. Вступление.

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

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

База данных создается для хранения в ней информации и получения этой информации при необходимости. Это значит, что мы должны иметь возможность помещать, вставлять (INSERT ) информацию в базу данных и мы хотим иметь возможность делать выборку информации из базы данных (SELECT ).
Язык запросов к базам данных был придуман для этих целей и был назван Структурированный язык запросов или SQL. Операции вставки данных (INSERT) и их выборки (SELECT) – части этого самого языка. Ниже приведен пример запроса на выборку данных и его результат.

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

Реляционная модель.

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

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

Примеры.

В качестве примеров в руководстве я использовал ряд приложений.

РСУБД.

РСУБД, которую я использовал для создания таблиц примеров – MySQL. MySQL – наиболее популярная РСУБД и она бесплатна.

Утилита для администрирования БД.

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

Визуальное моделирование.

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

Проектирование независимо от РСУБД.

Важно знать, что хотя в данном руководстве и приведены примеры для MySQL, проектирование баз данных независимо от РСУБД. Это значит, что информация применима к реляционным базам данных в общем, не только к MySQL. Вы можете применить знания из этого руководства к любым реляционным базам данных, подобным Mysql, Postgresql, Microsoft Access, Microsoft Sql or Oracle.

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

2. История.

В 70-х – 80-х годах, когда компьютерные ученые все еще носили коричневые смокинги и очки с большими, квадратными оправами, данные хранились бесструктурно в файлах, которые представляли собой текстовый документ с данными, разделенными (обычно) запятыми или табуляциями.

Так выглядели профессионалы в сфере информационных технологий в 70-е. (Слева внизу находится Билл Гейтс).

Текстовые файлы и сегодня все еще используются для хранения малых объемов простой информации. Comma-Separated Values (CSV) - значения, разделённые запятыми, очень популярны и широко поддерживаются сегодня различным программным обеспечением и операционными системами. Microsoft Excel – один из примеров программ, которые могут работать с CSV–файлами. Данные, сохраненные в таком файле могут быть считаны компьютерной программой.

Выше приведен пример того, как такой файл мог бы выглядеть. Программа, производящая чтение данного файла, должна быть уведомлена о том, что данные разделены запятыми. Если программа хочет выбрать и вывести категорию, в которой находится урок "Database Design Tutorial" , то она должна строчка за строчкой производить чтение до тех пор, пока не будут найдены слова "Database Design Tutorial" и затем ей нужно будет прочитать следующее за запятой слово для того, чтобы вывести категорию Software .

Таблицы баз данных.

Чтение файла строчка за строчкой не является очень эффективным. В реляционной базе данных данные хранятся в таблицах. Таблица ниже содержит те же самые данные, что и файл. Каждая строка или “запись” содержит один урок. Каждый столбец содержит какое-то свойство урока. В данном случае это заголовок (title) и его категория (category).

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

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

История реляционной модели.

Реляционная модель баз данных была изобретена в 70-х Эдгаром Коддом (Ted Codd), британским ученым. Он хотел преодолеть недостатки сетевой модели баз данных и иерархической модели. И он очень в этом преуспел. Реляционная модель баз данных сегодня всеобще принята и считается мощной моделью для эффективной организации данных.

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

- Oracle – используется преимущественно для профессиональных, больших приложений.
- Microsoft SQL server – РСУБД компании Microsoft. Доступна только для операционной системы Windows.
- Mysql – очень популярная РСУБД с открытым исходным кодом. Широко используется как профессионалами, так и новичками. Что еще нужно?! Она бесплатна.
- IBM – имеет ряд РСУБД, наиболее известна DB2.
- Microsoft Access – РСУБД, которая используется в офисе и дома. На самом деле – это больше, чем просто база данных. MS Access позволяет создавать базы данных с пользовательским интерфейсом.
В следующей части я расскажу кое-что о характеристиках реляционных баз данных.

3. Характеристики реляционных баз данных.

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

Использование ключей.

Каждая строка данных в таблице идентифицируется уникальным “ключом”, который называется первичным ключом. Зачастую, первичный ключ это автоматически увеличиваемое (автоинкрементное) число (1,2,3,4 и т.д). Данные в различных таблицах могут быть связаны вместе при использовании ключей. Значения первичного ключа одной таблицы могут быть добавлены в строки (записи) другой таблицы, тем самым, связывая эти записи вместе.

Используя структурированный язык запросов (SQL), данные из разных таблиц, которые связаны ключом, могут быть выбраны за один раз. Для примера вы можете создать запрос, который выберет все заказы из таблицы заказов (orders), которые принадлежат пользователю с идентификатором (id) 3 (Mike) из таблицы пользователей (users). О ключах мы поговорим далее, в следующих частях.

Столбец id в данной таблице является первичным ключом. Каждая запись имеет уникальный первичный ключ, часто число. Столбец usergroup (группы пользователей) является внешним ключом. Судя по ее названию, она видимо ссылается на таблицу, которая содержит группы пользователей.

Отсутствие избыточности данных.

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

Ограничение ввода.

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

Когда вы создаете таблицу базы данных вы предоставляете тип данных для каждого столбца. К примеру, varchar – это тип данных для небольших фрагментов текста с максимальным количеством знаков, равным 255, а int – это числа.

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

Эти ограничения дают вам контроль над целостностью ваших данных и предотвращают ситуации, подобные следующим:

Ввод адреса (текста) в поле, в котором вы ожидаете увидеть число
- ввод индекса региона с длинной этого самого индекса в сотню символов
- создание пользователей с одним и тем же именем
- создание пользователей с одним и тем же адресом электронной почты
- ввод веса (числа) в поле дня рождения (дата)

Поддержание целостности данных.

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

Назначение прав.

Большинство РСУБД предлагают настройку прав доступа, которая позволяет назначать определенные права определенным пользователям. Некоторые действия, которые могут быть позволены или запрещены пользователю: SELECT (выборка), INSERT (вставка), DELETE (удаление), ALTER (изменение), CREATE (создание) и т.д. Это операции, которые могут быть выполнены с помощью структурированного языка запросов (SQL).

Структурированный язык запросов (SQL).

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

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

Переносимость.

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

Как говорилось ранее, проектирование базы данных – это вопрос идентификации данных, их связи и помещение результатов решения данного вопроса на бумагу (или в компьютерную программу). Проектирование базы данных независимо от РСУБД, которую вы собираетесь использовать для ее создания.

В следующей части подробнее рассмотрим первичные ключи.

1. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

1.1. Реляционная база данных и ее структура

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

Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного вида. Каждая строка таблицы содержит данные об одном объекте (например, автомобиле, компьютере, клиенте), а столбцы таблицы содержат различные характеристики этих объектов –атрибуты (например, номер двигателя, марка процессора, телефоны фирм или клиентов).

Строки таблицы называются записями . Все записи таблицы имеют одинаковую структуру – они состоят изполей (элементов данных), в которых хранятся атрибуты объекта (рис. 1). Каждое поле записи содержит одну характеристику объекта и представляет собой заданный тип данных (например, текстовая строка, число, дата). Для идентификации записей используется первичный ключ.Первичным ключом называется набор полей таблицы, комбинация значений которых однозначно определяет каждую запись в таблице.

Рис. 1. Названия объектов в таблице

Для работы с данными используются системы управления базами данных (СУБД). Основные функции СУБД:

– определение данных (описание структуры баз данных);

– обработка данных;

– управление данными.

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

Любая СУБД позволяет выполнять следующие операции с данными:

– добавление записей в таблицы;

– удаление записей из таблицы;

– обновление значений некоторых полей в одной или нескольких записях в таблицах БД;

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

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

«язык структурированных запросов» (SQL – Structured Query Language).

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

1.2. Этапы проектирования реляционной базы данных

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

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

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

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

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

1.2.1. Определение требований

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

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

Таблица 1

Словарь данных для приложения БД менеджера турфирмы

Элемент данных	Описание
	Фамилия туриста
	Имя туриста
Отчество	Отчество туриста
	Серия и номер паспорта туриста
	Контактный телефон туриста
	Город проживания туриста
	Страна проживания туриста
	Почтовый индекс адреса туриста
	Название туристической поездки
	Цена туристической поездки
Дата начала	Время начала туристической поездки
Дата конца	Время завершения туристической поездки
Информация	Дополнительная информация о туре
Дата оплаты	Дата оплаты путевки
	Сумма оплаты

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

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

Функциональное описание для приложения БД менеджера турфирмы могло бы включать, например, следующие требования:

Приложением будут пользоваться руководитель турфирмы, 2 менеджера по продажам, бухгалтер, кассир и 2 офисных сотрудника турфирмы – всего 7 пользователей. Предполагается, что одновременно с БД будут работать не более 3 сотрудников. Персоналу бухгалтерии для работы достаточно иметь доступ только к данным по оплате путевок.

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

Один из офисных сотрудников будет назначен системным администратором. Только он должен вести учетные записи пользователей.

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

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

1.2.2. Логическая модель

ER-диаграммы

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

В примере менеджера турфирмы имеются 5 основных объектов:

Туристы

Туры

Путевки

Сезоны

Оплаты

Отношения между этими объектами могут быть определены простыми терминами:

Каждый турист может купить одну или несколько (много) путевок.

Каждой путевке соответствует ее оплата (оплат

может быть и несколько,
если путевка, например,
продана в кредит).
Каждый тур может иметь
несколько сезонов.

Путевка	продается
один сезон одного тура.
Эти объекты и отношения
могут быть представлены ER-
диаграммой,	как показано		Рис. 2. ER-диаграмма для приложения БД
				менеджера турфирмы

Объекты, атрибуты и ключи

Далее модель развивается путем определения атрибутов для каждого объекта. Атрибуты объекта – это элементы данных, относящиеся к определенному объекту, которые должны сохраняться. Анализируем составленный словарь данных, выделяем в нем объекты и их атрибуты, расширяем словарь при необходимости. Атрибуты для каждого объекта в рассматриваемом примере представлены в таблице 2.

		Объекты и атрибуты БД			Таблица 2
			Название	Дата начала	Дата оплаты
				Дата конца
	Отчество		Информация
Атрибуты

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

ляются, так как не являются, собственно, «натуральными» атрибутами объектов. Они обрабатываются по-другому и будут учтены в реляционной модели данных.

Реляционная модель характеризуется использованием ключей и отношений. Существует отличие в контексте реляционной базы данных терминов relation (отношение) и relationship (схема данных). Отношение рассматривается как неупорядоченная, двумерная таблица с несвязанными строками.Схема данных формируется между отношениями (таблицами) через общие атрибуты, которые являютсяключами .

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

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

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

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

	Объекты и атрибуты БД с расширенными кодовыми полями							Таблица 3
		Код туриста	Код путевки			Код сезона		Код оплаты
			Код туриста		Название	Дата начала		Дата оплаты
Атрибуты			Код сезона			Дата конца
		Отчество			Информация			Код путевки

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

Функциональные зависимости проявляются, когда значение одного атрибута может быть определено из значения другого атрибута. Атрибут, который может быть определен, называетсяфункционально зависимым от атрибута, который является детерминантом. Следовательно, по определению, все неключевые (без ключа) атрибуты будут функционально зависеть от первичного ключа в каждом отношении (так как первичный ключ уникально определяет каждую строку). Когда один атрибут отношения уникально не определяет другой атрибут, но ограничивает его набором предопределенных значений, это называетсямногозначной зависимостью.Частичная зависимость имеет место, когда атрибут отношения функционально зависит от одного атрибута составного ключа. Транзитивные зависимости наблюдаются, когда неключевой атрибут функционально зависит от одного или нескольких других неключевых атрибутов в отношении.

Процесс нормализации состоит в пошаговом построении БД в нормальной форме (НФ).

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

Вторая нормальная форма (2НФ) создается тогда, когда удалены все частичные зависимости из отношений БД. Если в отношениях не имеется никаких составных ключей, то этот уровень нормализации легко достигается.

Третья нормальная форма (3НФ) БД требует удаления всех транзитивных зависимостей.

Четвертая нормальная форма (4НФ) создается при удалении всех многозначных зависимостей.

БД нашего примера находится в 1НФ, так как все поля таблиц БД атомарные по своему содержанию. Наша БД также находится и во 2НФ, так как мы искусственно ввели в каждую таблицу уникальные коды для каждого объекта (Код Туриста, Код Путевки и т. д.), за счет чего и добились 2НФ для каждой из таблиц БД и всей базы данных в целом. Осталось разобраться с третьей и четвертой нормальными формами.

Обратите внимание, что они существуют только относительно различных видов зависимостей атрибутов БД. Есть зависимости – нужно стоить НФ БД, нет зависимостей – БД и так находится в НФ. Но последний вариант практически не встречается в реальных приложениях.

Итак, какие же транзитивные и многозначные зависимости присутствуют в нашем примере БД менеджера турфирмы?

Давайте проанализируем отношение «Туристы». Рассмотрим зависимости между атрибутами «Код туриста», «Фамилия», «Имя», «Отчество» и «Паспорт» (рис. 3). Каждый турист, представленный в отношении сочетанием «Фамилия- Имя-Отчество», имеет на время поездки только один паспорт, при этом полные тезки должны иметь разные номера паспортов. Поэтому атрибуты «Фамилия- Имя-Отчество» и «Паспорт» образуют в отношении туристы составной ключ.

Составной ключ

					Отчество
		Код туриста

Рис. 3. Пример транзитивной зависимости

Как видно из рисунка, атрибут «Паспорт» транзитивно зависит от ключа «Код туриста». Поэтому, чтобы исключить данную транзитивную зависимость, разобьем составной ключ отношения и само отношение на 2 по связям «один-к-одному». В первое отношение, оставим ему имя «Туристы», включаются атрибуты «Код туриста» и «Фамилия», «Имя», «Отчество». Второе отношение, назовем его «Информация о туристах», образуют атрибуты «Код туриста» и все оставшиеся атрибуты отношения «Туристы»: «Паспорт», «Телефон», «Город», «Страна», «Индекс». Эти два новых отношения уже не имеют транзитивной зависимости и находятся в 3НФ.

Многозначные зависимости в нашей упрощенной БД отсутствуют. Для примера предположим, что для каждого туриста должны храниться несколько контактных телефонов (домашний, рабочий, сотовый и пр., что весьма характерно на практике), а не один, как в примере. Получаем многозначную зависимость ключа – «Код туриста» и атрибутов «Тип телефона» и «Телефон», в этой ситуации ключ перестает быть ключом. Что делать? Проблема решается также путем разбиения схемы отношения на 2 новые схемы. Одна из них должна представлять информацию о телефонах (отношение «Телефоны»), а вторая о туристах (отношение «Туристы»), которые связываются по полю «Код туриста». «Код туриста» в отношении «Туристы» будет первичным ключом, а в отношении «Телефоны» – внешним.

1.2.3. Физическая модель

Физическая модель данных зависит от выбранной СУБД. Например, если вы планируете использовать СУБД Oracle, то физическая база данных будет состоять из файлов данных, областей таблиц, сегментов отката, таблиц, столбцов

и индексов.

В данном пособии будут рассмотрено создание физической модели БД средствами СУБД Microsoft Access и сервера баз данных Microsoft SQL Server 2005 Express Edition.

1.3. Создание БД в СУБД Microsoft Access

1.3.1. Таблицы

Для создания таблицы в СУБД Microsoft Access используем режим конструктора (рис. 4).

Рис. 4. Выбор режима конструктора

Рис. 5. Полный список полей таблицы

В появившемся окне «Таблица1: таблица» предстоит определить названия полей, которые и станут заголовками в этой таблице. Введем следующие названия полей (рис. 5).

		При вводе названия поля, для него
		по умолчанию определяется тип данных
		«текстовый». Для изменения типа следу-
		ет выбрать нужное значение из выпа-
		дающего списка (рис. 6).
Рис. 6. Определение типа данных поля		Описания возможных типов дан-
		ных Microsoft Access приводятся в таб-
		Таблица 4
	Типы данных Microsoft Access
Тип данных	Описание
Текстовый	Текст или комбинация текста и чисел, например, адреса, а также
	числа, не требующие вычислений, например, номера телефонов, ин-
	вентарные номера или почтовые индексы. Сохраняет до 255 знаков.
	Свойство «Размер поля» (FieldSize) определяет максимальное коли-
	чество знаков, которые можно ввести в поле
Поле МЕМО	Предназначено для ввода текстовой информации, по объему превы-
	шающей 255 символов. Такое поле может содержать до 65 535 сим-
	волов. Этот тип данных отличается от типа Текстовый (Text) тем, что
	щиеся отдельно. За счет этого ускоряется обработка таблиц (сорти-
	ровка, поиск и т. п.). Поле типа MEMO не может быть ключевым или
	проиндексированным
Числовой	Данные, используемые для математических вычислений, за исклю-
	чением финансовых	расчетов (для них следует использовать тип
	«Денежный»). Сохраняет 1, 2, 4 или 8 байтов. Конкретный тип чи-
	слового поля определяется значением свойства Размер поля (Field-
Дата/время	Значения дат и времени. Сохраняет 8 байтов
Денежный	Используется для денежных значений и для предотвращения округ-
	ления во время вычислений. Сохраняет 8 байтов
	Автоматическая вставка уникальных последовательных (увеличи-
	вающихся на 1) или случайных чисел при добавлении записи. Со-
	храняет 4 байта
Логический	Данные, принимающие только одно из двух возможных значений,
	таких, как «Да/Нет», «Истина/Ложь», «Вкл./Выкл.». Значения Null не
	допускаются. Сохраняет 1 бит.
Поле объекта	Объекты OLE (такие, как документы Microsoft Word, электронные
	таблицы Microsoft Excel, рисунки, звукозапись или другие данные в
	двоичном формате) (ограничивается объемом диска)

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

Содержание проектирования баз данных и этапность

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

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

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

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

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

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

Наконец, финальным этапом проектирования БД становится физическое проектирование – этап увязки логической структуры и физической среды хранения.

Таким образом, основные этапы проектирования в детализированном виде представлены этапами:

• инфологического проектирования,
• формирования требований к операционной обстановке
• выбора системы управления и программных средств БД,
• логического проектирования,
• физического проектирования

Ключевые из них ниже будут рассмотрены подробнее.

Инфологическое проектирование

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

• описание типов объектов,
• ограничения целостности, связанные с описанным типом,
• процессы, приводящие к эволюции предметной области – переходу её в другое состояние.

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

1. Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
2. Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
3. Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

Поскольку использование метода «сущность-связь» является комбинированным способом проектирования на данном этапе, он чаще других становится приоритетным.

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

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

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

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

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

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

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

Выбор системы управления и программных средств БД

От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:

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

Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.

Логическое проектирование БД

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

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

Здесь тоже находит отражение природа проектирования, которая допускает возможность (или необходимость) вернуться к концептуальной модели для её изменения в случае, если отражённые там взаимосвязи между объектами (или атрибуты объектов) не удастся реализовать средствами выбранной СУБД.

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

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

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

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

Физическое проектирование БД

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

Построение физической модели сопряжено с решением во многом противоречивых задач:

1. задачи минимизации места хранения данных,
2. задачи достижения целостности, безопасности и максимальной производительности.

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

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

Время от времени я заглядываю на Toster.ru и иногда даже отвечаю там на вопросы. Чаще всего люди спрашивают две вещи — как стать программистом и как правильно спроектировать схему базы данных. Мне лично кажется очень странным, что так много людей задают последний вопрос. Мне почему-то всегда казалось, что это такая простая вещь, которую умеют вообще все. Но, раз так много людей интересуются, здесь я постараюсь дать достаточно развернутый и в то же время краткий ответ.

Я предполагаю, что SQL вы знаете. То есть, объяснять, что такое таблицы, строки, индексы, первичные ключи и ссылочная целостность, не требуется. Если это не так, боюсь, я вынужден отправить вас к соответствующей литературе. Благо, ее сейчас очень много.

Рисуем диаграмму

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

Нарисовать следюущую диаграмму заняло у меня порядко десяти минут:

Если раньше вам не доводилось работать с такими диаграммами, не пугайтесь, тут все просто. Прямоугольнички — это таблицы, строки в прямоугольничках — имена столбцов, стрелочками обозначаются внешние ключи, а ключиками — первичные ключи. При желании тут можно разглядеть даже индексы, типы столбцов и обязательность их заполнения (null / not null), но для нас сейчас это не так важно.

Генерируем SQL и скармливаем его СУБД

Нетрудно заметить, что данная диаграмма легко отображается в код для создания схемы базы данных на языке SQL. В DbSchema сгенерировать SQL можно, сказав Schema → Generate Schema and Data Script. Затем полученный скрипт можно скормить используемой вами СУБД:

cat music.sql | psql -hlocalhost test_database test_user

Я использовал PostgreSQL. Информацию о том, как установить эту СУБД, вы найдете в этой заметке .

Итак, чем же я руководствовался при проектировании схемы?

Нормальные формы

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

Грубо говоря, таблица находится в первой нормальной форме (1НФ), если на пересечении любой строки и любого столбца в таблице находится ровно одно значение. В современных РСУБД это условие всегда выполняется. Даже если СУБД поддерживает множества или массивы, на пересечении строки и столбца хранится ровно одно значение типа множество или массив. Но в таблице (user varchar(100), phone integer) не может быть строки alex - 1234, 5678 . В 1НФ может быть только две сроки — alex - 1234 и alex - 5678 .

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

Таблица находится в третьей нормальной форме, если она находится в 2НФ и ни один неключевой атрибут не находится в транзитивной функциональной зависимости от первичного ключа. Например, рассмотрим таблицу (employee varchar(100) primary key, department varchar(100), department_phone integer) . Очевидно, что она находится в 2НФ. Но телефон отдела находится в транзитивной функциональной зависимости от имени сотрудника, так как сотрудник однозначно задает отдел, а отдел однозначно задает телефон отдела. Для приведения таблицы в 3НФ нужно разбить ее на две таблицы — employee - department и departmnet - phone .

Легко видеть, что нормализация уменьшает избыточность базы данных и препятствует внесению случайных ошибок. Например, если оставить таблицу из последнего примера в 2НФ, то можно по ошибке прописать одному и тому же отделу разные телефоны. Или рассмотрим компанию с пятью отделами и 1000 сотрудниками. Если у отдела поменялся номер телефона, то для его обновления в базе данных в случае 2НФ потребуется просканировать 1000 строк, а в случае с 3НФ только пять.

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования

«Российский экономический университет им. Г.В. Плеханова»

Факультет математической экономики и информатики

Кафедра информатики

КОМПЛЕКСНАЯ МЕЖДИСЦИПЛИНАРНАЯ

КУРСОВАЯ РАБОТА

По дисциплинам: «Базы данных»,

«Структуры данных и алгоритмы»

На тему: «Разработка базы данных библиотеки»

Выполнила:

студентка 427 группы

очной формы обучения

факультета математической экономики и информатики

Янушкевич Валерия Вадимовна

Научный руководитель:

Доцент, к.т.н.

Мосьяков Владимир Евгеньевич

Москва 2015

ВВЕДЕНИЕ 1. АНАЛИТИЧЕСКАЯ ЧАСТЬ 1.1. Анализ предметной области 1.2. Разработка контекстной диаграммы 1.3. Диаграммы декомпозиций 1.4. Ведение каталога 1.5. Ведение каталога книг 1.6. Ведение каталога читателей 1.7. Поисковая система 1.8. Система формирования заказов 1.9. Диаграммы дерева узлов 2. ОСНОВНАЯ ЧАСТЬ 2.1.Технология проектирования баз данных 2.2.Определение сущностей 2.3. Определение взаимосвязей между сущностями и создание модели данных 2.4. Задание первичных и альтернативных ключей, определение атрибутов сущностей 2.5. Приведение модели к требуемому уровню нормальной формы 2.6. Описание физической модели 2.7. Разработка меню, форм, инструментальных панелей и др. ЗАКЛЮЧЕНИЕ СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

ВВЕДЕНИЕ

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

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

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

Цель работы : разработать базу данных "Библиотека".

Задачи работы:

Спроектировать базу данных;

Установить связи между объектами предметной области;

Автоматизировать обновление и модификацию базы данных.

1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1. Анализ предметной области

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

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

Сформулируем требования к нашей работе

1. БД «Библиотека» предназначена для ввода, хранения и обработки информации о печатных изданиях, поступающих в библиотеку, а также, учёта сведения об абонентах библиотеки.
2. СУБД «Библиотека» должна обеспечить выполнение следующих действий:

• Прием новых читателей;
• Учет новых печатных изданий;
• Обеспечение соблюдения правил пользования литературой;

1.2. Разработка контекстной диаграммы

Контекстной диаграмма позволяет наглядно представить бизнес-процессы, протекающие в данной информационной системе, документооборот и информационные массивы. При построении данной диаграммы используется принцип иерархического упорядочивания – принцип организации составных частей системы. Построение иерархии диаграмм начинается с построения системы в виде простейшего компонента – одного блока и дуг. Дуги – это функции данной системы (входные и выходные данные, механизм работы системы и управляющая информация). Полученная модель может служить основой для создания программно-информационной системы. Исследуемым объектом является информационная система библиотеки, взаимодействие с внешней средой указано на рис.1.

Рис.1 Контекстная диаграмма функционирования библиотеки нотация IDEF 0

На вход информационной системы поступают:

• Книги;
• Люди;
• Запросы.

На выходе информационной системы получаются:

• Книги;
• Отказы читателей;
• Читатель.

Процессами управления являются:

• Нормативные акты;
• Особенности СУБД.

Для полноценной работы системы необходим квалифициованный персонал.

СУБД обеспечивает получение необходимой информации о наличии, приобретении, возврата книг, либо лично, либо по телефону.

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

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

За обеспечением работы всей системы следят люди (персонал). Обязанности работников регламентируются (нормативные акты).

1.3. Диаграммы декомпозиций

Вся библиотечная система состоит из трёх основных частей, а именно:

• Ведение каталога;
• Поисковой системы;
• Системы формирования заказов.

Взаимодействие этих блоков (подсистем) показано на рис.2.

Организация каталогов, занесение информации в базу данных, учёт книг, читателей всё это происходит в подсистеме «Ведение каталогов». Через неё проходят все книги, все читатели, это самый основной компонент информационной системы библиотеки, в нем осуществляется вся основная деятельность библиотеки.

Рис.2 Взаимодействие основных компонентов системы

Поисковая подсистема занимается непосредственной обработкой запросов от системы или запросов из вне, а так же предоставлением информации по этим запросам.

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

1.4. Ведение каталога

Подсистема ведения каталогов состоит из двух основных элементов: ведение каталога книг; ведение каталога читателей.

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

Рис.3 Подсистема ведения каталогов

1.5. Ведение каталога книг

Как и любой другой каталог, каталог ведения книг имеет такие основные компоненты:

• Формирование сведений о книге;
• Пополнение БД;
• Определение книг на склад.

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

Корректировка формирования информации о книги и её месторасположении осуществляется путём мелких запросов к базе данных, о наличии записей о похожих книгах рис.4.

Каждый компонент модуля ведения каталога книг рис.4., распадается на составные части, которые наглядно показаны на рис.5, рис.6, рис7.

На этапе формирования сведений о книге рис.5, выявляются данные по книжке, которые необходимо будет занести в библиотечную систему, название книги, её автор, тематика этой книги. Там же формируется цена на эту книгу, на основании нормативных актов, которыми обеспечивает руководство системы. На этапе формирования данных происходит уточнение, проверка уже наличия каких-то данных в системе по этим книгам.

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

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

1.6. Ведение каталога читателей

Устройство этого элемента системы очень схоже с «ведением каталога книг» рис.4, за одним исключением у него отсутствует блок «определения книг на склад», он здесь и не нужен. Так же блок «Пополнения БД читателей» видоизменён, если сравнивать его с «Пополнением БД» рис.10. Элемент «Сбор сведений» представлен на рис.9. Основные блоки «модуля ведения каталога читателей» представлены на рис.8.

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

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

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

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

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

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

1.7. Поисковая система

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

• Принятие запроса рис.13;
• Использование СУБД (по обработке запроса) рис.14;
• Формирование удобного вида отчёта рис.15.

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

1.8. Система формирования заказов

Сам процесс формирования заказа имеет в себе такие важные компоненты:

• Регистрация заказа рис.17;
• Формирование заказа рис.18;
• Оформление заказа рис.19;
• Выдача товара рис.20.

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

1.9. Диаграммы дерева узлов

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

Рис.21 Диаграмма дерева узлов библиотечной ИС глубины 4

Модель базы данных

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

Рис. 22 Логическая модель базы данных

2. ОСНОВНАЯ ЧАСТЬ

2.1.Технология проектирования баз данных

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

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

При рассмотрении требований конечных пользователей необходимо принимать во внимание следующее:

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

2.2.Определение сущностей

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

При проектировании базы данных книжного магазина можно выделить следующие сущности:

• читатель;
• печатное издание;
• выдача;
• каталог;
• читатель-задолжник;

2.3. Определение взаимосвязей между сущностями и создание модели данных

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

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

Определим для вышеперечисленных сущностей взаимосвязи.

Полученная после этого информационная модель представлена на рисунке 4.

Рисунок 25 – Информационная модель на втором этапе

Все связи между объектами (рисунок 6) являются связями «один ко многим», то есть одной записи данных первого объекта (основного) соответствует несколько записей второго объекта (подчиненного).

2.4. Задание первичных и альтернативных ключей, определение атрибутов сущностей

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

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

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

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

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

Таблица 1 - Первичные, альтернативные ключи и атрибуты

Сущность	Первичный ключ	Атрибуты
Информация о читателе	Номер билета	Номер билета Фамилия Имя Отчество Телефон Адрес
Информация о книге	Шифр книги	Шифр книги Название Код издательства Год издания Объем книги Цена Количество Код раздела
Выдача книг	Код выдачи	Код выдачи Шифр книги Код читательского билета Дата выдачи книги Дата возврата книги
Бронирование книг	Код брони	Код брони Шифр книги Код читательского билета Дата заказа
Издательства	Код издательства	Код издательства Наименование Код города
Города	Код города	Код города Наименование города
		Фамилия Имя Отчество
	Код записи	Код записи Шифр книги
Задолжники	Код задолжника	Код задолжника Фамилия Имя Отчество Дата выдачи
Разделы библиотеки	Код раздела	Код раздела Научная литература Журнальные публикации

2.5. Приведение модели к требуемому уровню нормальной формы

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

• Данные, представленные в виде плоской двумерной таблицы, являются первой нормальной формой реляционной модели данных. Первый этап нормализации заключается в образовании двумерной таблицы, содержащей все необходимые атрибуты информационной модели, в устранении составных (сложных) атрибутов и в выделении ключевых атрибутов. Первый этап нормализации модели системы представлен выше в таблице 1.
• Отношение задано во второй нормальной форме, если оно является отношением в первой нормальной форме и каждый атрибут, не являющийся первичным атрибутом в этом отношении, полностью зависит от любого возможного ключа этого отношения. Приведение отношений ко второй нормальной форме заключается в обеспечении полной функциональной зависимости всех атрибутов от ключа за счет разбиения таблицы на несколько таблиц, в которых все имеющиеся атрибуты имеют полную функциональную зависимость от ключа этой таблицы. В процессе приведения модели ко второй нормальной форме в основном исключаются аномалии дублирования данных, а также аномалии включения и удаления данных. Второй этап нормализации также можно наблюдать в таблице 1.
• Отношение задано в третьей нормальной форме, если оно задано во второй нормальной форме и каждый атрибут этого отношения, не являющийся первичным, нетранзитивно зависит от каждого возможного ключа этого отношения. Третий этап нормализации заключается в устранении аномалий включения и удаления данных. Он виден по таблице 1 и на рисунке 7.

В общем случае при проектировании базы данных необходимо соблюдать следующие правила:

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

2.6. Описание физической модели

	Наименование поля	Тип данных	Размер	Примечание
Информация о читателе
	Номер билета	Счетчик
	Фамилия	Текстовый
	Имя	Текстовый
	Отчество	Текстовый
	Телефон	Текстовый
	Адрес	Текстовый
Информация о книге
	Шифр книги	Счетчик
	Название	Текстовый
	Код издательства	Числовой	Длинное целое
	Год издания	Текстовый
	Объем книги	Числовой	Длинное целое
	Цена	Денежный
	Количество	Числовой	Длинное целое
	Код раздела	Числовой	Длинное целое
Выдача книг
	Код выдачи	Счетчик
	Шифр книги	Числовой	Длинное целое
	Код читательского билета	Числовой	Длинное целое
	Дата выдачи книги	Дата/время	Краткий формат даты
	Дата возврата книги	Дата/время	Краткий формат даты
Бронирование книг
	Код брони	Счетчик
	Шифр книги	Числовой	Длинное целое
	Код читательского билета	Числовой	Длинное целое
	Дата заказа	Дата/время	Краткий формат даты
Издательства
	Код издательства	Счетчик		Код издательства
	Наименование	Текстовый		Наименование издательства
	Код города	Числовой	Длинное целое
		Счетчик
	Фамилия	Текстовый
	Имя	Текстовый
	Отчество	Текстовый
	Код записи	Счетчик		Код записи
	Шифр книги	Числовой	Длинное целое
		Числовой	Длинное целое
Города
	Код города	Счетчик
	Наименование	Текстовый
Разделы библиотеки
	Код раздела	Счетчик
	Научная литература	Логический		Да или нет
	Журнальные публикации	Логический		Да или нет
Задолжники
	Код задолжника	Счетчик
	Фамилия	Числовой
	Имя	Числовой
	Отчество	Числовой
	Дата выдачи	Числовой

Расставим связи между таблицами (рисунок 5).

Рисунок 26– Схема данных

Все таблицы связаны между собой связью типа "Один-ко-многим". На примере таблиц "Издательства" и "Города" это означает, что одно издательство может иметь только один город, но в таблице "Издательства" может присутствовать множество записей таблицы "Города". Т.е. разные издательства могут иметь одинаковые названия городов.

Отчет по схеме:

Рисунок 27 – Схема данных

Аналогично связаны между собой остальные таблицы.

Основные характеристики используемой СУБД

В результаты мы получили СУБД, обладающую рядом характеристик.

Разработанная СУБД позволяет выполнять простейшие операции с данными:

Добавлять в таблицу одну или несколько записей;

Удалять из таблицы одну или несколько записей;

Обновлять значения некоторых полей в одной или нескольких записях;

Находить одну или несколько записей, удовлетворяющих заданному условию.

Разработанная СУБД организует хранение информации таким образом, чтобы ее было удобно:

Просматривать;

Пополнять;

Изменять;

Искать нужные сведения,

Делать любые выборки.

2.7. Разработка меню, форм, инструментальных панелей и др.

Разработаем формы для каждой из таблиц и занесем в них данные.

Рисунок 29 – Форма "Города"

Рисунок 30 – Форма "Издательства"

Рисунок 31– Форма "Информация о книге"

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

Рисунок 33 – Форма "Информация о читателе"

Рисунок 34– Форма "Бронирование книг"

В данной форме требуется ввести либо "Шифр книги" либо выбрать «Код читательского билета». Второе поле база данных установит самостоятельно.

Рисунок 35– Форма "Выдача книг"

Создадим главную кнопочную форму.

Рисунок 36 – Форма "Главная кнопочная форма"

Разработка запросов

Разработаем запросы.

1) Вывод сведений о книгах, взятых определенным читателем

SELECT [Выдача книг].[Код читательского билета], [Выдача книг].[Шифр книги], [Информация о книге].Название, Издательства.Наименование, [Выдача книг].[Дата выдачи книги], [Выдача книг].[Дата возврата книги]

FROM ([Информация о читателе] INNER JOIN ((Издательства INNER JOIN [Информация о книге] ON Издательства.[Код издательства] = [Информация о книге].[Код издательства]) INNER JOIN [Бронирование книг] ON [Информация о книге].[Шифр книги] = [Бронирование книг].[Шифр книги]) ON [Информация о читателе].[Номер билета] = [Бронирование книг].[Код читательского билета]) INNER JOIN [Выдача книг] ON [Информация о читателе].[Номер билета] = [Выдача книг].[Код читательского билета];

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

Рисунок 38 – Запрос "Сведения о читателях, у которых находится определенная книга"

Данный запрос, описанный в SQL:

SELECT [Информация о книге].[Шифр книги], [Информация о книге].Название, [Выдача книг].[Дата выдачи книги], [Выдача книг].[Дата выдачи книги], [Информация о читателе].Фамилия, [Информация о читателе].Имя, [Информация о читателе].Отчество

FROM [Информация о читателе] INNER JOIN ([Информация о книге] INNER JOIN [Выдача книг] ON [Информация о книге].[Шифр книги] = [Выдача книг].[Шифр книги]) ON [Информация о читателе].[Номер билета] = [Выдача книг].[Код читательского билета];

Данный запрос, описанный в SQL:

SELECT [Информация о читателе].[Номер билета], [Информация о читателе].[Фамилия], [Информация о читателе].[Имя], [Информация о читателе].[Отчество], [Информация о читателе].[Телефон], [Информация о читателе].[Адрес]

FROM [Информация о читателе];

Данный запрос, описанный в SQL:

Данный запрос, описанный в SQL:

SELECT [Информация о книге].[Код раздела]

FROM [Информация о книге]

WHERE ((([Информация о книге].[Код раздела])=1)) OR ((([Информация о книге].[Код раздела])=3));

Данный запрос, описанный в SQL:

SELECT [Информация о читателе].[Номер билета], [Выдача книг].[Дата возврата книги]

FROM [Информация о читателе] INNER JOIN [Выдача книг] ON [Информация о читателе].[Номер билета] = [Выдача книг].[Код читательского билета]

GROUP BY [Информация о читателе].[Номер билета], [Выдача книг].[Дата возврата книги];

Данный запрос, описанный в SQL:

SELECT [Информация о книге].[Шифр книги], [Информация о книге].[Год издания]

FROM [Информация о книге]

WHERE ((([Информация о книге].[Год издания])>"#2000#"));

Рисунок 44 – Запрос на выдачу не более 5 книг и сданную литературу до 01.01.2014 г.

Данный запрос, описанный в SQL:

SELECT [Информация о книге].Количество, [Информация о читателе].Фамилия, [Выдача книг].[Дата возврата книги]

FROM [Информация о книге] INNER JOIN ([Информация о читателе] INNER JOIN [Выдача книг] ON [Информация о читателе].[Номер билета] = [Выдача книг].[Код читательского билета]) ON [Информация о книге].[Шифр книги] = [Выдача книг].[Шифр книги]

WHERE ((([Информация о книге].Количество)>"5") AND (([Выдача книг].[Дата возврата книги])>#1/1/2014#));

Данный запрос, описанный в SQL:

SELECT Задолжники.Фамилия, Задолжники.Имя, Задолжники.Отчество, Задолжники.[Дата выдачи книги]

FROM Задолжники

WHERE (((Задолжники.[Дата выдачи книги])<#1/1/2013#));

ЗАКЛЮЧЕНИЕ

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

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

Разработанная программа устойчиво выполняет все свои функции. Учтена возможность обращаться к базе данных как лично, так и удалённо. В данной БД «Библиотека» предоставлена возможность работать как с бумажным оригиналом документа, так и с его копией. Поддерживается возможность удалённого доступа.

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Сеннов А. Access 2010. Учебный курс– СПб.: Питер, 2010. – 288с.:ил.
2. Рубин А.А., Клеандрова И.А., Прокди Р.Г. Самоучитель Access 2007. 100% результат уверенной работы– СПб.: Наука и Техника, 2011. – 400с.:ил.
3. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: учебное пособие. - М.: ФОРУМ: ИНФРА-М, 2007 – 400 с.: ил.
4. Кумскова И.А. Базы данных: учебник. – М.: КНОРУС, 2012. – 488 с.
5. Игорева, Е.Л., Основы алгоритмизации и программирования (3-е издание)./ И.И. Попов, О.Л. Игорева - М.: Инфа-М, 2013
6. Петгольц, Ч. Программирование #. В 3-х томах. Том 2. Пер. с англ./ Ч. Петгольц - М.: Издательско-торговый дом «Русская редакция», 2012.
7. Петгольц, Ч. Программирование. В 3-х томах. Том 3 Пер. с англ./ Ч. Петгольц - М.: Издательско-торговый дом «Русская редакция», 2012.
8. Глушаков С.В., Ломотько Д.В. Базы данных: Учебный курс. - Харьков: Фолио; Ростов н/Д: Феникс; Киев: Абрис, 2010.
9. Мишенин А.И. Теория экономических информационных систем - М.: Финансы и статистика, 2010.
10. Дженнингс Р.; Использование Microsoft Office Access 2014 - М: Издательский дом «Вильямс», 2014. - 1312 с.

выдача книг

Задолжники

итатели

Ведется учет

Книги (каталог книг)

Могут получать книги

Раздел

входят

Поиск книги

Может быть

Может

Осуществлять