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

1. Разработать эскиз концептуальной схемы БД.

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

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

4. Оформить графически концептуальную схему.

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

6. Создать в базе данных необходимые запросы.

7. Выполнить тестирование и корректировку созданных запросов.

Содержание отчета о работе

1. Концептуальная схема БД.

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

3. Перечень запросов к базе данных.

4. База данных (на дискете) дополненная необходимыми запросами.

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

1. Зачем, с Вашей точки зрения, необходим этап концептуального проектирования ИС?

2. Может ли изменяться тип связи, например от "один ко многим" к "многие ко многим", в зависимости от конкретных условий? Приведите примеры таких изменений.

3. В чем заключается сложность и важность этапа концептуального проектирования?

4. Какие типы запросов вы знаете?

5. Может ли параметрический запрос работать как запрос удаления? Если да, то объясните, как это сделать.

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

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

8. Зачем необходимы SQL-запросы?

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

Лабораторная работа № 5

ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ И СОЗДАНИЕ ОТЧЕТОВ

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

ТЕОРЕТИЧЕСКАЯ ЧЕСТЬ

Понятие логической модели базы данных

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

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

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

Логическая запись – это совокупность взаимосвязанных элементов данных разного типа. В простейшем случае запись содержит постоянное число элементов (Р₁, Р₂, ...,Р_k), называемых полями. Каждое поле Р имеет имя и представляет собой элемент данных определенного типа. Чаще всего используются числовые и символьные поля.

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

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

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

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

ВАГОН (НОМЕР ВАГОНА, ТИП ВАГОНА, КОД ОТПРАВИТЕЛЯ, КОД СТАНЦИИ ОТПРАВЛЕНИЯ МПС, КОД ПОЛУЧАТЕЛЯ, КОД СТАНЦИИ НАЗНАЧЕНИЯ МПС, КОД ЗАВОДСКОЙ СТАНЦИИ, КОД ГРУЗОВОГО ФРОНТА, КОД ГРУЗА, ВЕС ГРУЗА).

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