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

23.06.2019

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

Основные задачи:

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

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

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

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

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

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

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

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

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

Модели «сущность-связь»

Модель «сущность-связь» (англ. “Entity-Relationship model” ), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма , либо с использованием других графических нотаций (Crow"s Foot , Information Engineering и др.).

Основные преимущества ER-моделей:

наглядность;
модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

объекты (сущности);
атрибуты объектов;
связи между объектами.

Сущность - объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

типом связи (1:1, 1:N, N:М);
классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности - обязательный, иначе - необязательный.

Семантические модели

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

Дейт К. Дж. Введение в системы баз данных. - 8-е изд. - М.: «Вильямс», 2006:

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

Наиболее известным представителем класса семантических моделей является модель «сущность-связь» (ER-модель).

Литература

Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. - 8-е изд. - М .: «Вильямс», 2006. - 1328 с. - ISBN 0-321-19784-4
Когаловский М.Р. Перспективные технологии информационных систем. - М .: ДМК Пресс; Компания АйТи, 2003. - 288 с. - ISBN 5-279-02276-4
Когаловский М.Р. Энциклопедия технологий баз данных. - М .: Финансы и статистика, 2002. - 800 с. - ISBN 5-279-02276-4
Кузнецов С. Д. Основы баз данных. - 2-е изд. - М .: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с. - ISBN 978-5-94774-736-2
Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. - 3-е изд. - М .: «Вильямс», 2003. - 1436 с. - ISBN 0-201-70857-4
Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. - М .: «Вильямс», 2003. - 1088 с. - ISBN 5-8459-0384-X

См. также

Методы проектирования

Ссылки

Модель "сущность-связь" – шаг к единому представлению о данных - Citforum
Расширение реляционной модели для лучшего отражения семантики - Citforum
Пособие по проектированию баз данных сайтов "для начинающих"
Метод проектирования логической структуры реляционной БД без нормализации таблиц

Примечания

Wikimedia Foundation . 2010 .

Смотреть что такое "Проектирование баз данных" в других словарях:

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

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

ПРОЕКТИРОВАНИЕ - одна из форм опережающего отражения действительности, процесс создания прообраза (прототипа) предполагаемого объекта, явления или процесса посредством специфич. методов. П. является конкретной формой проявления прогностич. функции управления,… … Российская социологическая энциклопедия

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

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-
могут быть представлены ER-
диаграммой,	как показано	Рис. 2. 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. Определение типа данных поля		Описания возможных типов дан-
Рис. 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. Определение исходных таблиц базы данных.

4. Определение полей, которые будут входить в таблицы, и выбор полей, содержащих уникальные значения.

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

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

7. Создание форм, отчетов и запросов для операций с введенными данными.

Определение назначения базы данных

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

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

Выбор информации, включаемой в базу

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

2. Название книги.

3. Место издания (город).

4. Издательство (название издательства).

5. Год выпуска.

6. Аннотация.

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

1. Номер комнаты (помещения для хранения книг).

2. Номер стеллажа в комнате.

3. Номер полки на стеллаже.

4. Номер (инвентарный номер книги).

5. Дата приобретения.

6. Дата размещения конкретной книги на конкретном месте.

7. Дата изъятия книги с установленного места.

К атрибутам, позволяющим охарактеризовать читателей, можно отнести:

1. Номер читательского билета (формуляра).

2. Фамилия читателя.

3. Имя читателя.

4. Отчество читателя.

5. Адрес читателя.

6. Телефон читателя.

7. Дата выдачи читателю конкретной книги.

8. Срок, на который конкретная книга выдана читателю.

9. Дата возврата книги.

Определение исходных таблиц

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

2. Книги . Таблица предназначена для хранения сведений о книгах.

3. Издательства .Таблица предназначена для хранения сведений об издательствах.

4. Хранилище . Таблица предназначена для описания места хранения книг.

5. Выдача .Таблица предназначена для хранения сведений о выданных книгах.

6. Читатели .Таблица предназначена для хранения сведений о читателях библиотеки.

Выбор необходимых полей таблиц

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

Исходя из вышесказанного, определяем поля в выбранных таблицах и тип хранимых данных.

Книги:

· код книги – числовое поле, предназначено для однозначного определения каждой конкретной книги в базе данных;

· название книги

· аннотация – текстовое поле;

· дата издания ;

· дата поступления в библиотеку ;

· место хранения .
Издательства:

· код издательства – числовое поле, предназначено для однозначного определения каждого конкретного издательства в базе данных;

· название издательства – символьное поле, не более 256 символов;

· город, где расположено издательство – символьное поле, не более 25 символов.

Хранилище:

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

· номер комнаты – числовое поле;

· номер стеллажа – числовое поле;

· номер полки – числовое поле.

Выдача:

· код выдачи – числовое поле, предназначено для однозначного определения каждой конкретной выдачи в базе данных;

· номер выданной книги – числовое поле;

· код читателя – числовое поле;

· дата выдачи ;

· срок выдачи (количество дней);

· дата возврата .

Читатели:

· номер читательского билета – числовое поле, предназначено для однозначного определения каждого конкретного читателя в базе данных;

· фамилия

· имя – символьное поле, не более 50 символов;

· отчество – символьное поле, не более 50 символов;

· адрес – символьное поле, не более 256 символов;

· телефон – символьное поле, не более 20 символов.

Выбор уникальных полей

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

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

· Книги – код книги .

· Издательства – код издательства .

· Хранилище – код места .

· Выдача – код выдачи .

· Читатели – номер билета .

Назначение связей между таблицами

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

· один-к-одному – каждая запись таблицы А не может быть связана более чем с одной записью таблицы Б;

· один-ко-многим – одна запись в таблице А может быть связана со многими записями таблицы Б (например, в каждом классе может быть много учеников);

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

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

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

В нашей базе данных установим следующие типы связей между таблицами:

1. Авторы – Книги. Здесь связь многие-ко-многим , у любого автора может быть более одной книги, и любая книга может быть написана несколькими авторами. Поэтому вводим вспомогательную таблицу «Авторы–книги» со следующими полями:

· код книги .

2. Книги – Издательства. Здесь связь многие-ко-многим , любая книга может быть издана несколькими издательствами и любое издательство издает не одну книгу. Поэтому вводим еще одну вспомогательную таблицу «Книги–издательства» со следующими полями:

· код книги ;

· код издательства .

3. Хранилище – Книги. Здесь связь один-ко-многим , на одной полке можно расставить множество книг, но любая книга может быть только на одной полке в хранилище. Поэтому поле «Место хранения» в таблице «Книги» определяем как внешний ключ, и связываем таблицы «Хранилище» и «Книги» первичным ключом «Код места» и внешним ключом «Место хранения».

4. Книги – Выдача. Здесь связь один-ко-многим , т.е. одна и та же книга может быть выдана несколько раз в разные даты разным читателям. Поэтому поле «Номер выданной книги» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Книги» и «Выдача» первичным ключом «Код книги» и внешним ключом «Номер выданной книги».

5. Читатели – Выдача. Здесь связь один-ко-многим , т.е. одна и та же книга может быть выдана несколько раз разным читателям в разные сроки. Поэтому поле «Код читателя» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Читатели» и «Выдача» первичным ключом «Номер читательского билета» и внешним ключом «Код читателя».

Нормализация отношений

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

Правило 1: каждое поле таблицы должно представлять уникальный тип информации.

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

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

В спроектированной нами базе данных все таблицы (за исключением вспомогательных «Авторы – книги» и «Издательства – книги») содержат первичный ключ.

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

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

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

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

Наполнение базы данных, создание форм и отчетов

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

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

Полученная схема данных разработанной БД в MS Access представлена на рис. 4.1.

Рис. 4.1. Схема данных разработанной БД в Microsoft Access

Контрольные вопросы

1. Дайте определение информационной системы.

2. Поясните понятие базы данных.

3. Что такое предметная область?

4. Дайте определение СУБД.

5. Что такое модель данных?

6. Поясните основные принципы реляционной модели данных.

7. Поясните особенности СУБД Microsoft Access.

8. Каковы основные объекты базы данных Access?

9. Поясните структуру таблицы Access.

10. Поясните понятия: запрос, форма, отчет, страница доступа к данных, макрос, модуль.

11. Каковы основные этапы проектирования базы данных?

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

13. Поясните понятия: первичный ключ, внешний ключ.

14. Каково назначение связей между таблицами?

15. Поясните основные типы связей между таблицами.

16. В чем заключается нормализация отношений базы данных?

Процесс проектирования включает в себя следующие этапы.

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

Определение требований к операционной обстановке, в которой будет функционировать информационная система.

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

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

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

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

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

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

В настоящее время применяют проектирование с использованием метода "Сущность-связь"(entity–relation, ER–method), который является комбинацией предметного и прикладного методов и обладает достоинствами обоих.

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

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

Сущность – это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ ).

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

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

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

Характеристическая сущность ( характеристика ) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства.

Например, муж может иметь несколько жен, книга – несколько характеристик переиздания (исправленное, дополненное, ...) и т.д.

Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж.

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

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

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

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

Например, читатель библиотеки – сильная сущность, а абонемент этого читателя – слабая, которая зависит от наличия соответствующего читателя.

Слабые сущности называют подчинёнными (дочерними) , а сильные – базовыми (основными, родительскими) .

Для каждой сущности выбираются свойства (атрибуты).

Различают:

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

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

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

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

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

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

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

По типу различают множественные связи "один к одному" (1:1), "один ко многим" (1:n) и "многие ко многим" (m:n). ER–диаграмма, содержащая различные типы связей, приведена на рис. 1. Обратите внимание, что обязательные связи на рис. 1 выделены двойной линией.

Степень связи определяется количеством сущностей, которые охвачены данной связью. Пример бинарной связи – связь между отделом и сотрудниками, которые в нём работают. Примером тернарной связи является связь типа экзамен между сущностями ДИСЦИПЛИНА , СТУДЕНТ , ПРЕПОДАВАТЕЛЬ . Из последнего примера видно, что связь также может иметь атрибуты (в данном случае это Дата проведения и Оценка ). Пример ER–диаграммы с указанием сущностей, их атрибутов и связей приведен на рис. 2.

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

СОЗДАТЬ ТАБЛИЦУ Блюда *(Стержневая сущность)

ПЕРВИЧНЫЙ КЛЮЧ (БЛ)

ПОЛЯ (БЛ Целое, Блюдо Текст 60, Вид Текст 7)

ОГРАНИЧЕНИЯ (1. Значения поля Блюдо должны быть

уникальными; при нарушении вывод

сообщения "Такое блюдо уже есть".

2. Значения поля Вид должны принадлежать

набору: Закуска, Суп, Горячее, Десерт,

Напиток; при нарушении вывод сообщения

"Можно лишь Закуска, Суп, Горячее,

Десерт, Напиток");

СОЗДАТЬ ТАБЛИЦУ Состав *(Связывает Блюда и Продукты)

ПЕРВИЧНЫЙ КЛЮЧ (БЛ, ПР)

ВНЕШНИЙ КЛЮЧ (БЛ ИЗ Блюда

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Блюда КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ Блюда.БЛ КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ (ПР ИЗ Продукты

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Продукты ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Продукты.ПР КАСКАДИРУЕТСЯ)

ПОЛЯ (БЛ Целое, ПР Целое, Вес Целое)

ОГРАНИЧЕНИЯ (1. Значения полей БЛ и ПР должны принадлежать

набору значений из соответствующих полей таблиц

Блюда и Продукты; при нарушении вывод сообщения

"Такого блюда нет" или "Такого продукта нет".

2. Значение поля Вес должно лежать в пределах от 0.1 до 500 г.);

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

В ER диаграммах "Сущность-связь" сущности изображаются (рис.2) помеченными прямоугольниками , ассоциации – помеченными ромбами или шестиугольниками , атрибуты – помеченными овалами , а связи между ними – ненаправленными ребрами (линиями, соединяющими геометрические фигуры), над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.

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

(стержень)

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

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

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

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

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

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

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

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

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

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

ОБСТАНОВКЕ.

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

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

Федеральное агентство по образованию

Дагестанский Государственный Технический Университет

Факультет Информационных Систем

Кафедра ИСвЭ

Курсовой проект

«Разработка базы данных»

Выполнила: ст-ка 3 курса

Гр. И411 Вагабова П.Х.

Проверил: ст. преподаватель

Каф. ИСЭ Мурадов М.М.

Махачкала 2006г.

1.Введение

Теоритическая часть

1 «Анализ предметной области»

2 «Проектирование БД»

3 «Обзор современных СУБД»

4 «Обоснование выбора технических средств»

Проектная часть

1 Модули программ

2 Описание работы с программой

Заключение

Литература

Приложение

1.Введение

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

Рациональное и умелое использование широких возможностей ЭВМ- серьезная проблема настоящего этапа развития общества, актуальность решения которой растет по мере увеличения парка ЭВМ и совершенствования их технического и программного оснащения.

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

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

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

2. Теоретическая часть

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

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

Так как XXI век- век компьютерной техники, то просто не имеет смысла вести учёт вручную, перебирать кипу бумаг в надежде найти то, что нас интересует, достаточно сформировать БД в C++Builder и поиск нужных данных будет осуществляться намного быстрее.

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

В моей курсовой учёт ведётся по следующим полям:

· ФИО мастера,

· Номер машины,

· Количество выпущенной продукции,

· Наименование изделия,

· Материал,

· Артикул ткани,

· Название ткани,

· Производитель ткани,

· Расход ткани,

· Цена ткани,

· Артикул красителя,

· Название красителя,

· Производитель красителя,

· Расход красителя,

· Цена красителя.

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

2 Проектирование БД

В БД отражается определенная информация о предметной области.

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

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

Инфологическая модель:

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

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

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

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

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

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

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

Требования, предъявляемые к инфологической модели:

Адекватное отображение предметной области- язык для представления ИЛМ должен обладать достаточными выразительными возможностями для отображения явлений, имеющих место в предметной области.

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

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

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

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

Должна быть легко реализуемой на ЭВМ.

Должна быть независимой от оборудования и языков организации БД на ЭВМ.

Основные конструктивные элементы инфологической модели:

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

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

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

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

Даталогическая модель базы данных (ДЛМ):

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

Физическая модель БД:

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

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

В настоящее время наблюдается тенденция к сокращению работ на стадии физического проектирования. Иногда эти работы вообще бывают скрыты от проектировщика.

база данное язык программирование

2.3 Обзор современных СУБД

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

В наиболее полном варианте пакеты СУБД должны иметь следующие компоненты:

Среда пользователя, дающая возможность непосредственно управления БД.

Алгоритмический язык для программирования прикладных систем обработки данных.

Компилятор для придания завершенной программе готового коммерческого вида, в виде exe-файла.

Программы- утилиты быстрого программирования рутинных операций, такие как FORM, MENU.

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

Основная особенность СУБД - это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).

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

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

Известно много программных продуктов, позволяющих создавать и работать с БД, например, Access, Clipper, Excel и другие. Среди большого разнообразия программ наибольшей популярностью пользуется СУБД FoxPro, которая по своим характеристикам удовлетворяет самым высоким требованиям, предъявляемым такого типа системам как по уровню и объему, так и по скорости обработки информации.

На данный момент разработано и широко используется Visual FoxPro для Windows версий 3.0 и 5.0. Однако, работа с этими пакетами для непрограммистов представляет собой довольно сложную задачу. Поэтому для создания БД для пользователей, имеющих небольшой опыт в программировании, очень удачными являются версии 2.5 и 2.6 под Windows и 2.0 под DOS.

Структура Базы данных:

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

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

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

Среда разработки Borland С++ Builder.

Для создания автономного рабочего места можно выбрать программные средства языка « С++ Builder» , которое является одной из наиболее известных СУБД. На рынке программных продуктов есть много средств для автоматизации программирования. Но по мощности и удобству использования со средой Builder может соперничать лишь Borland Delphi и Microsoft Visual Basic.

« С++ Builder» является мощной системой визуального объектно-ориентированного программирования, которая позволяет работать как с простыми локальными удаленными БД, так и с многозвенными распределенными БД. Она сама и поставляемые с ней программные продукты позволяют решать следующий круг задач:

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

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

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

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

Создавать системы работы с локальными и удаленными БД любых типов.

Создавать БД различных типов с помощью инструментария С++ Builder (DataBaseDesktop).

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

Связываться со своего приложения с такими продуктами Microsoft как Word, Excel и др.

Создавать систему помощи, как для своих приложений, так и для других.C++Builder 6 - это программа, созданная для управления данными - каталогизации, поддержки, обработки информации и многое другое. Хотя Вы можете производить многие операции базы данных через систему меню и интерфейс, овладение обширными возможностями Borland C++Builder 6 требует некоторого знания лежащего в основе языка программирования.

Приложения в среде Borland С++ Builder 6 строятся в виде специальных конструкций - проектов, которые выглядят для пользователя как совокупность нескольких файлов. Ни одна программа не может существовать вне структуры-проекта. Действия по управлению проектами осуществляет специальный программный комплекс - Менеджер проектов.

4 Обоснование выбора технических средств

Минимальные системные требования:

Операционная система Microsoft Windows 98, Windows Millennium (Me), Windows 2000 и поздние версии операционных систем Microsoft Windows.

3. объем оперативной памяти должен составлять не менее 128 Mb (256 Mb рекомендуется).

4. 115 Mb свободного места на жестком диске.

VGA или более высокое разрешение монитора.

Мышь, клавиатура.

Пространство на жестком диске, необходимое для полной установки: 675 Mb (Enterprise edition); 580 Mb (Professional); 480 Mb (Personal)

3. Проектная часть

Задание: Выпуск продукции и расход сырья. Структура файлов БД:

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

Формы документов: сведения о человеке, выпускающем продукцию за месяц, сведения о людях, выпускающих продукцию за месяц.

На основании теоретических данных построим инфологическую (Рис.3.1) и даталогическую (Таб.3.1, Таб.3.2) модели данных.

Рис.3.1 инфологическая модель предметной области.

Таблица 3.1.

«Схема данных выпуск продукции и расход сырья»

наименование	назначение	размерность
ФИО мастера
	дата выпуска
	номер машины
	кол.вып продукции
	наим. изделий
	материал

Таблица 3.2.

«Схема данных материал»

наименование	назначение	размерность
	материал
	артикул ткани
	название ткани
	произволитель ткани
	расход ткани
	цена ткани
	артикул красителя
	название красителя
произволитель красителя
	расход красителя
	цена красителя

Схема таблиц.

Откроем Пуск->Программы->Borland C++ Builder 6->BDE Administrator. Создадим БД: Object->New и назовем ее «КБД».

Откроем Пуск->Программы->Borland C++ Builder 6->Database Desktop. В ней создадим две таблицы (New->Table), которые назовем:

3.1 Модули программ

Данное приложение содержит одну главную форму Form1. Она запускает ряд процедур, которые являются модулями программ.

Список процедур:

Table1AfterScroll- обеспечивает отображение данных Таблицы1 (“t1.db”) в окне редактирования при перемещении по таблице.AfterScroll- обеспечивает отображение данных Таблицы2 (“t2.db”) в окне редактирования при перемещении по таблице.Click- обеспечивает отображение данных таблиц в окне редактирования при перемещении по таблице с помощью компоненты навигации по базе данных.Click- переводит Таблицы 1 и 2 (“t1.db” , “t2. db ”) в состояние режима вставки (dsInsert), а также очищает поля ввода данных.Click- редактирует содержимое Таблиц 1 и 2 (“t1.db” , “t2. db”).Click- сохраняет данные, внесенные в окна редактирования, для Таблиц 1 и 2 (“t1.db ” “t2.db”).Click- удаляет данные из Таблиц 1 b 2 (“t1.db ” и “t2.db”).Click- очищает поля ввода данных.Click- выводит отчет QuickRep1 на экран.Click- выводит отчет QuickRep1 на печать.Click- осуществляет переход на Form2.Click- осуществляет выход из программы.Click- осуществляет фильтрацию Таблицы1 (“t1.db”).Change- осуществляет фильтрацию Таблицы1 (“t1.db”) по полю N_mash Change- осуществляет фильтрацию Таблицы1 (“t1.db”) по полю Naim_iz Change- осуществляет поиск данных Таблицы1 (“t1.db”) по полю Fio_vas(используется метод Locate).Change- осуществляет поиск данных Таблицы1 (“t1.db”) по полю Data_v(используется метод Locate).

Form2- используется для вывода справки о программе на экран.

Схема взаимосвязи программных модулей:

2 Описание работы с программой

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

Операция ввода позволяет вводить в базы данных следующие данные: ФИО мастера, дата выпуска, номер машины, количество выпущенной продукции, наименование изделия, материал, артикул ткани, название ткани, производитель ткани, расход ткани, цена ткани, артикул красителя, название красителя, производитель красителя, расход красителя, цена красителя. Для того чтобы осуществить ввод новых данных необходимо нажать на кнопку Ввод -> ввести нужные данные в поля ввода -> Сохранить.

Нажав Удалить, можно удалить запись. Редактировать запись можно следующим образом: к примеру в Edit1 введём новую фамилию мастера и нажмём на кнопку «редактировать», изменения должны отобразиться в таблицах.

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

Поиск осуществляется по ФИО мастера и дате выпуска. Введя в поле ввода ФИО нужного нам мастера, будут высвечиваться все данные об этом мастере. Фильтрация осуществляется по номеру машины и наименованию изделия. К примеру мы можем ввести в поле Edit34 наименование изделия, установить значок «наименование изделия» и в наших таблицах выведутся все данные относительно этого изделия.

4.Заключение

В результате проделанной работы я ознакомилась с программой C++Builder и создала БД «выпуск продукции и расход сырья».

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

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

5. Литература

1. Диго С.М. “Использование и проектирование базы данных”.

2. Курс лекций по дисциплине “Базы данных”.

Никита Культин “Самоучитель С++ Builder ” Санкт-Петербург <<БВХ-Петербург>> 2004 г.

Хеннер Е.К., Могилев А.В., Пак Н.И. «Информатика». М.: «Учебное пособие для студентов пед. вузов», 1999 г.

Б. Бабэ «Просто и ясно о Borland C++»;

Т. Сван «Программирование для Windows в Borland C++ Builder»;

Д. Холингворт, Б. Сворт, М. Кэшмэн, П. Густавсон «Borland С++ Builder»;

М. Фленов «Программирование на Borland C++ Builder глазами хакера»;