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

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

Политехнический институт

Кафедра "Автоматизированные станочные системы"

Троицкий Д.И. доцент, к.т.н.

МЕТОДИЧЕСКИЕ УКАЗАНИЯ

ПО ВЫПОЛНЕНИЮ ЛАБОРАТОРНОЙ РАБОТЫ №5

по дисциплине

ПРОГРАММИРОВАНИЕ

Направление подготовки:

230100 Информатика и вычислительная техника

Профиль подготовки:

Системы автоматизированного проектирования

Форма обучения – очная, очно-заочная, заочная

Тула 2011 г.

Рассмотрено на заседании кафедры "Автоматизированные станочные системы"

протокол №1 от "31" августа 2011 г.

Зав. кафедрой________________А.Н. Иноземцев

Содержание

1. Общие сведения о базах данных 4

2. Проектирование структуры БД 5

3. Нормализация структур баз данных 7

4. Начало работы с MS Access 10

1.1. Задание на работу 11

1.2. Порядок выполнения работы 11

5. Список использованных источников 20

1. Общие сведения о базах данных

В любом наборе исходных данных самая надежная величина,

не требующая никакой проверки, является ошибочной.

Из законов Мэрфи

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

Рис. 1.1 – Типичная реляционная БД.

Существует несколько форматов файлов баз данных. Наиболее часто применяются базы форматов Access (расширение .mdb), Paradox (.db), InterBase (.gdb). Программа, написанная на Delphi, может взаимодействовать как с этими, так и с многими другими видами БД (dBase, FoxPro, Access) на основе единого подхода. С точки зрения написания программы нет никакой разницы, работаете вы с базами Paradox, dBase или Access. Это достигается тем, что операции с БД могут выполняться при помощи специального языка SQL (Structural Query Language). Кроме того, SQL обеспечивает многопользовательский доступ к БД, что автоматически делает вашу программу сетевой.

2. Проектирование структуры бд

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

этого проекта тогда и только тогда, когда чертежи уже выполнены.

Из законов Мэрфи

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

Проектирование БД ставит перед собой следующие цели:

1. Возможность хранения в БД всех необходимых данных.

2. Исключение избыточности данных.

3. Сведение числа хранимых в БД таблиц к минимуму.

4. Нормализация отношений для легкого обновления и удаления записей.

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

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

1. Требование редактируемости БД. Если одна и та же информация хранится в разных местах, то при необходимости ее обновления/удаления придется просмотреть все записи в базе, что неприемлемо.

2. Требование компактности БД. Дублирование информации приводит к разрастанию БД, что не только расходует место в памяти машины, но и замедляет работу СУБД с такой базой. Использование специальных методов нормализации БД, которые будут рассмотрены ниже, приводит к резкому сокращению размеров БД. Например, размер справочника телефонов Тулы в исходном виде составляет 10Мб, а после нормализации - менее 3Мб (обратите внимание, что речь не идет о сжатии информации, а только о ее более рациональной организации).

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

Имя поля	Тип данных	Длина, символов
PRODUCT	текст	200
FIRM	текст	200

Рис. 2.2 – Первоначальная структура БД.

Здесь в поле PRODUCT хранится наименование изделия, а в поле FIRM - наименование покупателя. Сама БД выглядит примерно следующим образом:

PRODUCT	FIRM
Привод	ОАО "Электроприбор"
Задвижка	ООО "Арматура"
Задвижка	ОАО "Электроприбор"
Привод	ООО "Арматура"

Рис. 2.3 – Заполненная БД.

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