(ассоциация)

(характеристика)

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

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

объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;

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

образование классов и подклассов подобных объектов (например, класс "изделие" и подклассы типов изделий, производимых на предприятии).

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

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

ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ОПЕРАЦИОННОЙ

ОБСТАНОВКЕ.

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

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

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

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

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

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

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

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

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

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

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

Выполнила:

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

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

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

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

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

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

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

Москва 2015

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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 с.

выдача книг

Задолжники

итатели

Ведется учет

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

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

Раздел

входят

Поиск книги

Может быть

Может

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

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 основных объектов:

Туристы

Туры

Путевки

Сезоны

Оплаты

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

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

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

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

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

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

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

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

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

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

Для проектируемой БД расширим атрибуты объектов кодовыми полями в качестве первичных ключей и используем эти коды в отношениях БД для ссылки на объекты БД следующим образом (табл. 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).

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

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

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

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

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

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

Построение информационно-логической модели данных предметной области;

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

Конструирование таблиц базы данных;

Создание схемы данных;

Ввод данных в таблицы (создание записей);

Разработка необходимых форм, запросов, макросов, модулей, отчетов;

Разработка пользовательского интерфейса.

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

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

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

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

Рассмотрим формальные правила, которые могут быть использованы для выделения информационных объектов:

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

Определить функциональные зависимости между атрибутами;

Выбрать все зависимые атрибуты и указать для каждого все его ключевые атрибуты, т. е. те, от которых он зависит;

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

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

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

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

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

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

Проектирование базы данных на основе модели типа объект — отношение

Имеется целый ряд методик создания информационно-логических моделей. Одна из наиболее популярных в настоящее время методик при разработке моделей использует ERD (Entity-Relationship Diagrams). В русскоязычной литературе эти диаграммы называют «объект — отношение» либо «сущность — связь». Модель ERD была предложена Питером Пин Шен Ченом в 1976 г. К настоящему времени разработано несколько ее разновидностей, но все они базируются на графических диаграммах, предложенных Ченом. Диаграммы конструируются из небольшого числа компонентов. Благодаря наглядности представления они широко используются в CASE-средствах (Computer Aided Software Engineering).

Рассмотрим используемую терминологию и обозначения.

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

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

Каждая сущность должна обладать некоторыми свойствами:

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

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

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

Сущность может быть независимой либо зависимой. Признаком зависимой сущности служит наличие у нее наследуемых через связь атрибутов (рис. 1.).

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

Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Одна из участвующих в связи сущностей — независимая, называется родительской сущностью, другая — зависимая, называется дочерней или сущностью-потомком. Как правило, каждый экземпляр родительской сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров дочерней сущности. Каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности-родителя.

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

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

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

Продавец может получить вознаграждение за один или более Контрактов;

Контракт должен быть инициирован ровно одним Продавцом.

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

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

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

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

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

Характер идентификации отображается в диаграмме на линии связи (рис. 4).

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

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

В настоящее время на основе подхода Чена создана методология IDEF1X , которая разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEFlX-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой «/» и помещаемые над блоком.

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

Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. На рис. 5: №2 — зависимая сущность, Связь 1 — идентифицирующая связь. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).

Штриховая линия изображает неидентифицирующую связь. На рис. 5: №4 — независимая сущность, Связь 2 — неидентифицирующая связь. Сущность-потомок в неидентифицируюшей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

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

В IDEF1X могут быть выражены следующие мощности связей:

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

Каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

Каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

Каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

Мощность связи обозначается, как показано на рис. 6 (мощность по умолчанию — N).

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

В результате получается информационно-логическая модель, которая используется рядом распространенных CASE-средств, таких, как ERwin, Design/IDEF. В свою очередь, CASE-технологии имеют высокие потенциальные возможности при разработке баз данных и информационных систем, а именно, увеличение производительности труда, улучшение качества программных продуктов, поддержка унифицированного и согласованного стиля работы.

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

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

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

§ демонстрируют заказчику работу аналогичной базы данных, после чего согласо­вывают спецификацию отличий;

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

При подготовке технического задания составляют:

Список исходных данных, с которыми работает заказчик;

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

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

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

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

a. Работа начинается с составления генерального списка полей - он может насчи­тывать десятки и даже сотни позиций.

b. В соответствии с типом данных, размещаемых в каждом поле, определяют наиболее подходящий тип для каждого поля.

c. Далее распределяют поля генерального списка по базовым таблицам. На первом этапе распределение производят по функциональному признаку. Цель - обеспе­чить, чтобы ввод данных в одну таблицу производился, по возможности, в рамках одного подразделения, а еще лучше - на одном рабочем месте. Наметив столько таблиц, сколько подразделений охватывает база данных, при­ступают к дальнейшему делению таблиц. Критерием необходимости деления является факт множественного повтора данных в соседних записях. Бывает так, что у таблицы в поле Адрес наблюдается повтор данных. Это явное свидетельство того, что таблицу надо поделить на две взаимосвязанные таблицы.

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

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

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

Рассмотрим таблицу Клиенты. Здесь поле Код клиента является ключе­вым. Это понятно, поскольку у каждого клиента должен быть свой уникальный код, идентифицирующий его однозначно. Если мы рассмотрим таблицу Заказы, то увидим, что в ней код клиента не может быть уникальным, поскольку каж­дый клиент мог сделать сколь угодно много заказов. На схеме данных эти поля соединены линией связи. С одной стороны эта линия маркирована знаком «1», с другой стороны - значком «бесконечность». Это графический метод изображе­ния связи «один ко многим».

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

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

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

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

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

III. Характеристика СУБД Microsoft Access 2000

СУБД Microsoft Access 2000 предоставляет несколько средств создания каждого из основных объектов базы. Эти средства можно классифицировать как:

Ручные (разработка объектов в режиме Конструктора);

Автоматизированные (разработка с помощью программ-мастеров);

Автоматические - средства ускоренной разработки простейших объектов.

Соотношения между этими средствами понятны: ручные средства являются наибо­лее трудоемкими, но обеспечивают максимальную гибкость; автоматизированные и автоматические средства являются наиболее производительными, но и наименее гибкими.

Методической особенностью изучения программы Microsoft Access явля­ется тот факт, что в учебных целях для создания разных объектов целесообразно пользоваться разными средствами:

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

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

Работа с таблицами

Создание таблиц. Работа с любыми объектами начинается с окна База данных (рис.6.12). На левой панели данного окна сосредоточены элементы управления для вызова всех семи типов объектов программы. Создание таблиц начинается с выбора элемента управления Таблицы.

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

Рис.6.12. Окно База данных является исходным элементом

управления программы Microsoft Access 2000

Окно Конструктора таблиц представлено на рис.6.13а. То, что мы видим в этом режиме, фактически является графическим бланком для создания и редактирования структуры таблиц.

В первом столбце вводят имена полей. Если свойство Подпись для поля не задано, то Имя поля станет одновременно и именем столбца будущей таблицы. Тип для каждого поля выбирают из раскрывающегося списка, открывае­мого кнопкой выбора типа данных (рис. 6.14). Эта кнопка - скрытый элемент управления. Она отображается только после щелчка на поле бланка. Это надо иметь в виду - в Microsoft Access очень много таких скрытых элементов управления, кото­рые не отображаются, пока ввод данных не начат.

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

Рис. 6.14. Выбор типа поля в таблице

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

Если первичный ключ необходим для связи с другими таблицами, но ни одно из полей не является уникальным, то первичный ключ можно создать на базе двух (или более полей). Эта операция выполняется точно так же, через контекстное меню, надо только уметь выделить сразу несколько полей. Группо­вое выделение выполняют при нажатой клавише SHIFT щелчками на квадратных маркерах слева от имен полей. Закончив создание структуры таблицы, бланк закрывают (при этом система выдает запрос на сохранение таблицы), после чего дают таблице имя, и с этого момента она доступна в числе прочих таблиц в основном окне База данных. Оттуда ее и можно открыть в случае необходимости.