АЛМАТИНСКИЙ ИНСТИТУТ ЭНЕРГЕТИКИ И СВЯЗИ
Кафедра инженерной кибернетики
Проектирование баз данных
Методические указания
к выполнению расчетно-графических работ
для студентов всех форм обучения специальности
050718 - Электроэнергетика
Алматы 2010
СОСТАВИТЕЛИ: В.М. Тарасов, Ю.В. Шевяков. Проектирование баз данных. Методические указания к выполнению расчетно-графических работ для студентов всех форм обучения специальности 050718 – Электроэнергетика. – Алматы: АИЭС, 2010. – 26 с.
Представлены методические указания к выполнению расчетно-графических работ дисциплины «Проектирование баз данных» для студентов всех форм обучения специальности 050718 – Электроэнергетика. Они содержат систематизированные сведения и рекомендации, которые могут быть использованы студентами очного и заочного отделений при выполнении расчетно-графических работ.
Введение
Современные системы обработки информации выполняют преобразования больших массивов данных. Обеспечение практической эффективности современных информационных систем потребовало выделить в самостоятельные функциональные проблемы задачи организации, хранения, поиска и независимости обработки данных.
Концепция баз данных, являющаяся методологической основой современных информационных систем, сформулирована в 70-х годах прошлого столетия. Предложенная Коддом реляционная модель данных и бурная эволюция компьютерных систем определили информационные системы как основной инструмент в области современных информационных технологий.
Настоящие методические указания составлены в соответствии с программой курса «Проектирование баз данных».
Целью курса проектирования баз данных является изучение методов и средств проектирования баз данных, ориентированных на применение в конкретной предметной области.
Студент, изучающий курс ПБД, должен выполнить расчетно-графическую работу. Ниже приведены варианты заданий по РГР. Номер варианта у студентов очного обучения определяется преподавателем. У студентов заочного обучения вариант определяется по двум последним цифрам шифра зачётной книжки студента как остаток от целочисленного деления на 25. Например, две последние цифры 37, делим 37 целочисленно на 25 37:25=1 (12). Полученный остаток 12 и определяет вариант.
Рекомендации по выполнению РГР
РГР должна быть выполнена на ПК в среде СУБД (рекомендуется MS ACCESS). Спроектируйте модель для указанной предметной области, позволяющую ответить на указанный круг вопросов. Преобразуйте созданную модель в реляционную модель. Выполните нормализацию таблиц. Создайте таблицы в Access и установите свойства полей. Создайте схему данных. Заполните таблицы данными. Выполните поиск нужной информации в БД.
Требования к выполнению РГР
РГР печатается на листах А4 с полями: левое – 25 мм, правое – 18 мм, верхнее – 20 мм, нижнее – 25 мм. Текст выполняется с помощью Word черным шрифтом с кеглем не менее 12 на белом фоне. Отступ первой строки 5 символов. В таблицах и рисунках допустим размер шрифта 11 кеглей.
РГР должна содержать:
- титульный лист;
- верхний колонтитул на каждой странице с указанием номера варианта, автора;
- нижний колонтитул с номерами страниц по центру;
- задание;
- универсальное отношение или начальный набор сущностей;
- этапы нормализации таблиц или сущностей;
- схему БД;
- заполненные таблицы;
- созданные запросы и диаграмму;
- требуемые отчеты.
1 Этапы проектирования данных
Предполагается, что студенты перед выполнением РГР прослушали лекции и выполнили лабораторные работы, т.е. имеют представление о правилах создания БД и знакомы с основами работы с БД.
Напомним еще раз определение понятия - "предметная область":
Предметная область - часть реального мира, подлежащая изучению с целью организации управления и автоматизации. Предметная область представляется множеством фрагментов, например, предприятие - цехами, дирекцией, бухгалтерией и т.д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты.
В теории проектирования информационных систем предметную область принято рассматривать в виде трех представлений:
- представление предметной области в том виде, как она реально существует;
- как ее воспринимает человек (имеется в виду проектировщик БД);
- как она может быть описана с помощью символов.
Рисунок 1.
Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой пользователем (см. рисунок 1). Концептуальная схема является полной совокупностью всех требований к данным, полученным из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.
Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:
1. Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие действия:
- обследование предметной области, изучение ее информационной структуры;
- выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами;
- моделирование и интеграция всех представлений.
2. По окончании данного этапа получаем концептуальную модель "сущность-связь".
Пример проектирования БД
Рассмотрим пример проектирования БД для автоматизации работы деканата в ВУЗе. Пусть требуется создать базу данных Деканат, которая учитывала бы сдачу всеми студентами плановых предметов в каждом семестре. Кроме того, БД должна учитывать работу преподавателя в часах. Требуемые отчеты:
- Результаты зимней сессии.
- Студенты – отличники.
- Дисциплины, сданные с 19 по 21 октября.
- Количество часов преподавателей в зимнем семестре.
Естественно, что сущность Студент должна обязательно присутствовать, в ней должны быть аргументы, описывающие конкретного студента: Код студента (РК), ФИО студента, Пол, Телефон студента, и сервисные поля Группа, Староста и ФИО эдвайзера. Первичный ключ Код студента введен из-за возможного наличия студентов-тезок.
Анализ предметной области показал, что, исходя из современной практики проставления рубежных оценок и экзаменационных оценок, необходимо дисциплину представлять в виде нескольких независимых названий. Вместо ТОЭ следует писать ТОЭ лекции, ТОЭ практика, ТОЭ лабораторные.
Перечень дисциплин в сессии определяется сущностью Учебный план. В ней должен быть ключевой аргумент, описывающий конкретные дисциплины (ТОЭ лекции, ТОЭ лабораторные и ТОЭ практика и т.д.), и неключевые аргументы: форма отчетности (рубежный контроль или экзамен), количество часов, запланированных для обучения, ФИО преподавателя и сервисные аргументы для преподавателя: телефон преподавателя, кафедра, телефон кафедры и другие. Для контроля объема работы преподавателя в часах добавим аргументы Поток и Количество студентов. Количество студентов в потоке или в группе определяет количество часов, затраченных преподавателем на проверку РГР, курсовых работ, время на экзамены. Однако аргумент Дисциплина не может быть ключевым. Действительно, одну и ту же дисциплину в разных потоках, например, «ТОЭ лаб» в потоке БЭ-09-1, БЭ-09-2 и БЭ-09-3 может вести один или несколько преподавателей. Следовательно, этот аргумент может повторяться, поэтому введем ключевой аргумент Код дисциплины.
Для контроля того, как учатся студенты, должна быть сущность, учитывающая, какую оценку получил каждый студент на экзамене или рубежном контроле по каждой дисциплине и дату. ФИО преподавателя, принявшего экзамен, здесь указывать не требуется, он полностью определен ключевым свойством Дисциплина из сущности Учебный план. Назовем эту сущность Ведомость. В ней должны быть аргументы Код студента, Код дисциплины, выполняющие роль составного ключевого аргумента, и неключевые аргументы Оценка и Дата сдачи.
Между сущностями требуется найти связи, которые часто обозначаются глаголами, но могут обозначаться и существительными. В теории нет строгого определения, что следует называть сущностью, а что связью. На схемах сущности показываются в прямоугольниках, а связи - в ромбиках. Все выявленные сущности и связи между ними показаны на рисунке 2.
Рисунок 2 – Начальная ER-диаграмма
Все сущности превратим в одноименные таблицы, а аргументы сущностей представим одноименными полями (см. рисунок 3).
Чтобы БД не имела потенциальной противоречивости и избыточности (каждый факт должен отражаться один раз на своем месте), все таблицы должны находиться в первой, второй и третьей нормальных формах (1НФ, 2НФ и 3НФ).
Все созданные таблицы находятся в 1НФ, поскольку все данные в полях атомарны и их нельзя упростить.
Все таблицы находятся во 2НФ, поскольку все поля однозначно функционально зависят от первичных ключей.
Таблицы не находятся в 3НФ, поскольку есть поля, функционально, однозначно зависящие от неключевых полей (показано стрелочками) на рисунке 3. Следовательно, необходимо привести таблицы к 3НФ с помощью нормализации (декомпозиции).
Введем понятия проекции таблицы и полной декомпозиции таблицы.
Рисунок 3 – Представление сущностей в виде отношений
Проекцией таблицы называют новую таблицу, полученную после удаления некоторых полей. Полной декомпозицией таблицы называют такую совокупность ее проекций, соединение которых полностью совпадает с содержимым первоначальной таблицы.
2 Процедура нормализации
Рассмотрим процедуру приведения таблиц к 3НФ (НФБК). Она основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости, когда первичный ключ однозначно определяет любое поле. Принцип «один факт в одном месте» говорит о том, что не должно существовать в рамках таблицы никаких других функциональных зависимостей. Цель нормализации и состоит в удалении этих «других» функциональных зависимостей.
Рассмотрим два возможных варианта нормализации.
Вариант 1. Таблица имеет составной первичный из полей DK, EК и включает поля А, В, С. Пусть поле А функционально зависит только от части составного ключа, только от поля EК (см. рисунок 4). В этом случае рекомендуется сформировать дополнительную таблицу, содержащую поле EК (в качестве первичного ключа) и поле А. Неключевое поле А из первоначальной таблицы удаляется. В первоначальной таблице останутся поля DK, EК, В, С.
 |
Рисунок 4.
Вариант 2. Таблица имеет первичный ключ СК, а также поля А и В. Пусть поле А функционально зависит от ключа СК и от не ключевого поля В. При нормализации формируется дополнительная таблица, содержащая поле ВK (как первичный ключ) и поле А. Поле А удаляется из первоначальной таблицы и в первоначальной таблице останутся поля СК и В.
СК, А, В è СК, В + ВК , А.
Повторяя применение двух рассмотренных правил нормализации таблиц, для любой таблицы, не находящейся в 3НФ (НФБК), можно получить, в конечном счете, множество более простых таблиц. Все они будут находиться в 3НФ (НФБК) и не будут содержать каких-либо дополнительных функциональных зависимостей.
В отношении Студенты, приведенном на рисунке 3, поля Староста и Эдвайзер функционально зависят не только от ключевого поля Код студента, но и от неключевого поля Группа. Устраняем эту зависимость согласно варианту 2 (см. рисунок 5).
Рисунок 5 – Результат декомпозиции таблицы Студенты
Рисунок 6 - Результат декомпозиции таблицы Учебный план
В таблице Учебный план (см. рисунок 3) аналогичная ситуация: поле Телефон кафедры зависит от неключевого поля Кафедра, а поле Кол. студентов зависит от неключевого поля Поток; поля Телефон преподавателя и Должность зависят от неключевого поля ФИО преподавателя. Поступая аналогично предыдущему, разбиваем таблицу Учебный план на четыре проекции: Учебный план, Потоки, Кафедры, Преподаватели, причем в таблицы Кафедры, Преподаватели, имеется возможность добавить сервисные поля, зависящие только от первичных ключей таблиц, что было и сделано. В таблицу Кафедры добавлены поля ФИО заведующего и Аудитория. В Таблицу Преподаватели добавлено поле Адрес и из-за возможного наличия тезок введено ключевое поле Код преподавателя. В отношении Учебный план останутся поля, показанные на рисунке 6.
Попробуем заполнить отношение Учебный план (см. таблицу 1). Как видим поля Форма отчетности и Кол. часов зависят не только от ключевого поля Код дисциплины, но и от неключевого поля Дисциплина.
Т а б л и ц а 1 – Отношение Учебный план
|
Код дисциплины (РК) |
Дисциплина |
Форма отчетности |
Кол часов |
Код преподавателя |
Поток |
|
2 |
ТОЭ лек. |
Экзамен |
32 |
Тайцев Л.К. |
БЭ-09-1,2,3,4 |
|
5 |
ТОЭ лаб. |
Рубеж |
32 |
Турова Л.Б. |
БЭ-09-1 |
|
6 |
ТОЭ лаб. |
Рубеж |
32 |
Титова Л.Б. |
БЭ-09-2 |
|
7 |
Физика лек. |
Экзамен |
32 |
Факов Л.К. |
БЭ-09-1,2,3,4 |
|
8 |
Физика лаб. |
Рубеж |
16 |
Феменов Л.Б. |
БЭ-09-1 |
|
9 |
Физика лаб. |
Рубеж |
16 |
Феменов Л.Б. |
БЭ-09-2 |
Выполним повторно декомпозицию таблицы Учебный план, разбив ее на две новых согласно варианту 2 (см. рисунок 7).
Рисунок 7 – Нормализация отношения Учебный план
Теперь все таблицы базы данных приведены к 3НФ.
Рассмотрим отношение Ведомость (см. рисунок 3). Поля Оценка и Дата зависят от составного ключа ФИО студента и Дисциплина. Действительно, оценка ставится конкретному студенту по конкретной дисциплине в день определенный учебным планом. ФИО преподавателя всегда можно вставить в ведомость при формировании запроса по результатам экзаменов. Следовательно, таблица Ведомость также находится в 3НФ. Схема полученной БД приведена на рисунке 8.
Созданная БД не является избыточной и потенциально противоречивой, поскольку каждый факт указан только один раз на своем месте. При указании типа связи между таблицами в MS Access мы имеем право установить все свойства связи: обеспечение целостности данных, каскадное обновление связанных полей и каскадное удаление связанных записей. Эти установки значительно ускоряют ввод данных и автоматически гарантируют целостность БД.
Рисунок 6 – Полная схема БД
Обратите внимание, что все таблицы соединены между собой последовательными связями по часовой стрелке. Нет связей, которые возвращались бы от последующей таблице к какой-либо предыдущей таблице. Отсутствуют в таблицах повторяющиеся поля, кроме ключевых полей, служащих для связи между таблицами, которые заполняются только в главных таблицах и поэтому не являются избыточными.
Определение типов данных
Следующий этап проектирования — определение доменов (типов данных), хранящихся в полях таблиц. Параллельно с заданием типа необходимо сформулировать ограничения целостности, связанные с типом, и диапазон допустимых значений данных.
Исходя из особенностей значений полей, задаются типы данных и диапазон их возможных изменений для каждого из полей таблиц. Например, если в поле предполагается хранить доли в процентах от общего количества, то следует задать числовой тип и указать диапазон возможных значений — от 0 до 100.
Далее, в каждой таблице должны быть выделены поля, которые обязательно должны быть заполнены при создании каждой записи таблицы. Задание такого ограничения целостности не позволит, например, ввести в таблицу Студенты запись, в которой не указан номер группы. Если подобные ограничения целостности не будут заданы, в таблице могут появиться записи , которые не будут учтены при обработке данных. Это приведет к ошибкам при формировании ведомости с помощью запроса.
Следующий шаг — задание для полей значений по умолчанию. Значение по умолчанию впоследствии будет автоматически вводиться в указанное поле для каждой записи таблицы. Например, в поле Дата сдачи таблицы Ведомость при заполнении очередной записи по умолчанию может автоматически заноситься текущая дата.
В программе MS Access указанные ограничения вносятся в свойства полей.
Т а б л и ц а 2 – Свойства полей отношения Студенты
|
Имя поля |
Код студента |
ФИО студента |
Группа |
Пол |
Стипендия |
|
Подпись |
|
|
|
|
|
|
Тип данных |
Счетчик |
Текстовый |
Текстовый |
Текстовый |
Денежный |
|
Значение по умолчанию |
|
|
БЭ-09- |
|
|
|
Условие на значение |
|
|
|
|
>=0 And <=15000 |
|
Обязательное поле |
|
Да |
Нет |
Нет |
Нет |
|
Пустые строки |
|
Нет |
Да |
Да |
Да |
|
Индексированное поле (ключевое) |
Да (совпадения не допускаются) |
Нет |
Нет |
Нет |
Нет |
|
Подстановка |
|
|
|
Муж, Жен из списка |
|
Ниже рассмотрены свойства полей в Access.
Имя – служит для управления БД, как переменная в программировании.
Подпись – применяется при необходимости сделать наименование поля более наглядными. Подпись выводится на экран или бумагу вместо имени поля.
Значение по умолчанию – применяется для автоматического вывода часто встречающихся данных, например, надписи или даты.
Условие на значение – определяет диапазон допустимых значений поля, например, диапазон значений оценки от 0 до 9 баллов.
Обязательное поле – поле, в котором установлено требование обязательного его заполнения. Например, поле Группа для таблицы Студенты.
Пустые строки – можно разрешить наличие пустой ячейки в поле. Например, можно разрешить не заполнять поле Телефон.
Индексированное поле (ключевое поле) – для первичного простого ключа повторения запрещаются, для составного первичного ключа повторения значений в полях допускаются, но не допускаются повторения комбинаций данных в ключевых полях.
Подстановка – служит для заполнения поля данными либо из фиксированного списка, или данными из одноименного поля главной таблицы, значения которого используются как список, причем значения в списке автоматически меняются при изменении значений в ячейках поля в главной таблице.
Следующая таблица Экзамены, связанная с таблицей Студенты, в ней даты сдачи экзаменов устанавливаются с разностью в 3 дня.
Таблица 3 – Свойства полей отношения Экзамены (без поля Оценка)
|
Имя поля |
Код записи |
Код студента |
Дата сдачи ТОЭ |
Оценка по ТОЭ |
Дата сдачи физики |
|
Подпись |
|
ФИО студента |
|
|
|
|
Тип данных |
Счетчик |
Числовой |
Дата/время
|
Числовой |
Дата/время
|
|
Значение по умолчанию |
|
|
Текущая дата Date() |
|
Текущая дата плюс 3 дня Date()+3 |
|
Условие на значение |
|
|
|
>=0 And <=9 |
|
|
Обязательное поле |
|
Да |
Да |
Да |
Да |
|
Пустые строки |
|
|
Нет |
|
Нет |
|
Индексированное поле (ключевое) |
Да (совпадения не допускаются) |
Нет |
Нет |
Нет |
Нет |
|
Подстановка |
|
Из таблицы Студенты |
|
|
|
3. Варианты заданий на РГР
Вариант 00
Предметная область: «Комплектация персональных компьютеров». Предполагается выполнение следующих процессов:
- учет комплектов ПК;
- учет поставок комплектов и комплектующих;
- ведение справочника поставщиков изделий.
Перечень отчетов:
- сведения об указанном комплекте (состав комплекта их количество );
- сведения о наличии указанного комплектующего изделия;
- сведения об имеющихся изделиях у указанного поставщика.
Вариант 01
Предметная область: «Учет материалов на складе». Предполагается выполнение следующих процессов:
- учет поступивших материалов за определенный период;
- учет материалов на хранении у указанного материально-ответственного лица;
- учет выбывших материалов.
Перечень отчетов:
- отчет о материалах, находящихся на ответственном хранении у указанного материально-ответственного лица;
- отчет о поступивших материальных ценностях в определенный период с указанием ФИО материально-ответственного лица;
- отчет о выбывших материальных ценностях указанного номенклатурного номера.
Вариант 02
Предметная область: «Студенческая библиотека».
Предполагается учет следующей информации:
- учет имеющегося книжного фонда;
- ведение каталога читателей;
- учет выданных и возвращенных книг.
Перечень отчетов:
- книги указанного автора, имеющихся в библиотеке на указанную дату;
- список книг, выданных указанному читателю;
- поиск книги по фрагменту названия.
Вариант 03
Предметная область: «Учет измерительных приборов в лаборатории стандартизации» Выполняемые процедуры:
- учет приборов, поступивших на поверку за определенный период;
- учет приборов, прошедших поверку за определенный период;
- учет приборов, не прошедших поверку, с указанием отдела, откуда они поступили.
Перечень отчетов:
- отчет о приборах, не прошедших поверку из указанного отдела;
- отчет о приборах, которые должны поступить на поверку в определенный период и из каких отделов;
- отчет о приборах, которые должны проходить поверку 1 раз в месяц, 1 раз в 6 месяцев, 1 раз в год.
Вариант 04
Предметная область: «Кадры предприятия».
Предполагается выполнение следующих процессов:
- ведение справочника сотрудников;
- учет вакантных мест;
- учет движения кадров.
Перечень отчетов:
- сведения об указанной группе сотрудников (сотрудники одного отдела, сотрудники с высшим образованием и т.д.);
- сведения об имеющихся вакансиях;
- сведения об уволенных сотрудниках за какой-то период.
Вариант 05
Предметная область: «Учет заявок на выполнение работ (услуг) рекламного агентства». Выполняемые процедуры:
- ведение каталога услуг (прайс-листы);
- учет поступивших заявок;
- учет выполнения заявок (по срокам, объемам, исполнителям).
Перечень отчетов:
- отчет об услугах, выполненных в определенный период;
- отчет об объеме (стоимости) работ, выполненных указанным исполнителем;
- отчет о невыполненных работах, услугах.
Вариант 06
Предметная область: «Формирование ремонтных ведомостей». Выполняемые процедуры:
- ведение справочника «Расценки на ремонтные работы»;
- составление ремонтных ведомостей;
- составление калькуляций на выполнение ремонта.
Перечень отчетов:
- перечень принятых заявок на ремонт в определенный период;
- ремонтная ведомость по указанному номеру заявки;
- калькуляция по указанному ремонту.
Вариант 07
Предметная область: «Выставка электротехнического оборудования».
Выполняемые процедуры:
- ведение каталога участников выставки;
- учет выставленных экспонатов.
Перечень отчетов:
- список участников выставки, зарегистрированных на определенную дату;
- сведения об указанном экспонате с указанием участника;
- отчет по группам экспонатов (количество и кто их представляет);
Вариант 08
Предметная область: «Научная конференция».
Выполняемые процедуры:
- учет состава участников конференции;
- учет мероприятий конференции (расписание мероприятий);
- учет докладов, сообщений участников.
Перечень отчетов:
- сведения о мероприятиях, проводимых в указанное время указанной даты;
- сведения об участниках, представивших доклад на заданную тему;
- сведения о докладах, сообщениях, сделанных указанным участником.
Вариант 09
Предметная область: «Расписание движения поездов». Выполняемые процедуры:
- ведение расписания поездов:
- получение информации о составе поездов и количестве мест.
Перечень отчетов:
- расписание поездов указанного направления;
- сведения о количестве мест в вагонах указанного типа (плацкарта, купе, общий), указанного поезда;
- сведения о составе указанного поезда, сколько вагонов и какие вагоны.
Вариант 10
Предметная область: «Расписание авиарейсов» Выполняемые процедуры:
- ведение расписания вылетов и прилетов авиарейсов;
- получение информации о наличии свободных мест и стоимости авиабилетов.
Перечень отчетов:
- расписание рейсов указанного направления;
- сведения о количестве свободных мест указанного рейса;
- сведения о рейсах, выполняемых указанной авиакомпанией.
Вариант 11
Предметная область: «Банковские операции». Выполняемые процедуры:
- учет клиентов банка;
- ведение счетов клиентов банка;
- учет прихода и расхода денежных средств.
Перечень отчетов:
- список счетов и клиентов, взявшим кредит в указанном квартале;
- список клиентов, счета которых неактивны в определенный период;
- список клиентов, сумма на счетах которых превышает указанную сумму.
Вариант 12
Предметная область: «Студенческая библиотека». Выполняемые процедуры:
- учет имеющегося книжного фонда;
- учет выданных и возвращенных книг за указанный день;
- ведение каталога читателей.
Перечень отчетов:
- список книг, выданных указанному читателю в указанный день;
- поиск книги по названию (автору) с указанием читателя, если книга на руках;
- список книг указанного автора, которые имеются в читальном зале.
Вариант 13
Предметная область: «Студенческая конференция».
Выполняемые процедуры:
- учет участников конференции;
- учет докладов, стендов по секциям.
Перечень отчетов:
- список участников конференции указанного научного руководителя;
- отчет об участии в конференции по факультетам;
- список участников конференции, выступающих с докладами в указанный день.
Вариант 14
Предметная область: «Студенческая олимпиада». Выполняемые процедуры:
- учет участников по различным видам спорта;
- учет участников, имеющих различные квалификации;
- учет участников по различным возрастным группам.
Перечень отчетов:
- список призеров по различным видам спорта;
- список участников одного факультета, ставших призерами;
- сведения об участниках указанного вида спорта.
Вариант 15
Предметная область: «Сборка персональных компьютеров». Предполагается выполнение следующих процессов:
- учет комплектов ПК;
- учет поставок комплектов и комплектующих;
- ведение справочника поставщиков и комплектующих;
Перечень отчетов:
- сведения об указанном комплекте (состав комплекта, количество комплектов);
- сведения о наличии указанного комплектующего изделия;
- сведения об имеющихся изделиях указанного поставщика.
Вариант 16
Предметная область: «Склад комплектующих изделий электротехнической фирмы».
Предполагается выполнение следующих процессов:
- учет поступивших материалов за определенный период;
- учет материалов на ответственном хранении у указанного материально-ответственного лица;
- учет выбывших материалов.
Перечень отчетов:
- отчет о материалах, находящихся на ответственном хранении у указанного материально – ответственного лица;
- отчет о поступивших материальных ценностях в определенный период с указанием ФИО материально-ответственного лица;
- отчет о выбывших материальных ценностях указанного номенклатурного номера.
Вариант 17
Предметная область: «Учет контрольно – измерительных приборов в лаборатории подразделения КИП».
Выполняемые процедуры:
- учет приборов, поступивших на поверку за определенный период;
- учет приборов, прошедших поверку за определенный период;
- учет приборов , не прошедших поверку, с указанием отдела, откуда он поступил.
Перечень отчетов:
- отчет о приборах, не прошедших поверку из указанного отдела;
- отчет о приборах, которые должны поступить на поверку в определенный период с указанием отделов;
- отчет о приборах, которые должны проходить поверку 1 раз в месяц, 1 раз в 6 месяцев, 1 раз в год.
Вариант 18
Предметная область: «Кадры электротехнического предприятия». Предполагается выполнение следующих процессов:
- ведение картотеки сотрудников;
- учет вакантных мест;
- учет движения кадров.
Перечень отчетов:
- сведения об указанной группе сотрудников (сотрудники одного отдела, сотрудники с высшим образованием и т.д.);
- сведения об имеющихся вакансиях;
- сведения об уволенных сотрудниках за определенный период.
Вариант 19
Предметная область: «Фирма по ремонту бытовой электротехники». Выполняемые процедуры:
- ведение справочника «Расценки на ремонтные работы»;
- составление ремонтных ведомостей;
- составление калькуляций на выполнение ремонта.
Перечень отчетов:
- перечень принятых заявок на ремонт в определенный период;
- ремонтная ведомость по указанному номеру заявки;
- расчетная калькуляция по указанному ремонту.
Вариант 20
Предметная область: «Рекламное агентство». Выполняемые процедуры:
- ведение каталога услуг (прайс-листы);
- учет поступивших заявок;
- учет выполнения заявок по срокам, объемам, исполнителям.
Перечень отчетов:
- учет выбывших материалов.
- отчет об услугах, выполненных в определенный период;
- отчет об объеме (стоимости) работ, выполненных указанным исполнителем;
- отчет о невыполненных работах, услугах.
Вариант 21
Предметная область: «Клиенты коммерческого банка» Выполняемые процедуры:
- учет клиентов банка;
- ведение счетов клиентов банка;
- учет прихода и расхода денежных средств.
Перечень отчетов:
- список счетов и клиентов, рассчитавшихся с кредитом в указанном квартале;
- список клиентов, взявших кредит;
- список клиентов, сумма на счетах которых превышает указанное значение.
Вариант 22
Предметная область: «Расписание движения поездов ст. Алматы». Выполняемые процедуры:
- ведение расписания поездов:
- получение информации о составе поездов и количестве мест.
Перечень отчетов:
- расписание поездов указанного направления;
- сведения о количестве мест в вагонах указанного типа (плацкарта, купе, общий), указанного поезда;
- сведения о составе указанного поезда.
Вариант 23
Предметная область: «Расписание авиарейсов из Аэропорта г. Астаны». Выполняемые процедуры:
- ведение расписания вылетов и прилетов авиарейсов;
- получение информации о наличии свободных мест и стоимости авиабилетов.
Перечень отчетов:
- расписание рейсов указанного направления;
- сведения о количестве свободных мест в указанных классах указанного рейса;
- сведения о рейсах, выполняемых указанной авиакомпанией.
Вариант 24
Предметная область: «Студенческая спартакиада». Выполняемые процедуры:
- учет участников по различным видам спорта;
- учет участников, имеющих различные квалификации;
- учет участников по различным возрастным группам.
Перечень отчетов:
- список призеров по различным видам спорта;
- список участников одного факультета, ставших призерами;
- сведения об участниках указанного вида спорта.
Приложение А
Образец выполнения РГР
Некоммерческое акционерное общество
АЛМАТИНСКИЙ ИНСТИТУТ ЭНЕРГЕТИКИ И СВЯЗИ
Расчетно-графическая работа
по ПБД
Вариант 33
Выполнил: студент группы
БЭ-09-11 Иванов М.И.
Проверил: ст. преподаватель Павлов В.М.
Алматы 2010
Задание.
Требуется создать базу данных Деканат, которая учитывала бы сдачу всеми студентами плановых предметов в каждом семестре. Кроме того, БД должна учитывать работу преподавателя в часах. Требуемые отчеты:
1. Результаты зимней сессии.
2. Студенты – отличники.
3. Дисциплины, сданные с 19 по 21 октября.
4. Количество часов преподавателей в зимнем семестре (график).
Проектирование БД
Естественно, что сущность Студент должна обязательно присутствовать, в ней должны быть аргументы, описывающие конкретного студента: Код студента (РК), ФИО студента, Пол, Телефон студента, и сервисные поля Группа, Староста и ФИО эдвайзера. Первичный ключ Код студента введен из-за возможного наличия студентов-тезок.
Перечень дисциплин в сессии определяется сущностью Учебный план. В ней должен быть ключевой аргумент, описывающий конкретные дисциплины (ТОЭ лекции, ТОЭ лабораторные и т.д.), и аргументы, описывающие форму отчетности (рубежный контроль или экзамен), количество часов, запланированных для обучения, ФИО преподавателя и сервисные аргументы преподавателя: телефон преподавателя, кафедра, телефон кафедры и другие. Для контроля объема работы преподавателя в часах добавим аргументы Поток и Количество студентов. Количество студентов в потоке или в группе определяет количество часов, затраченных преподавателем на проверку РГР, курсовых работ, время на экзамены.
Для контроля того, как учатся студенты, должна быть сущность, учитывающая, какую оценку получил каждый студент на экзамене или рубежном контроле по каждой дисциплине и дату. ФИО преподавателя, принявшего экзамен, здесь указывать не требуется, преподаватель полностью определен ключевым свойством Дисциплина из сущности Учебный план. Назовем эту сущность Ведомость. В ней аргументы Код студента, Дисциплина играют роль составного ключевого аргумента и имеются неключевые аргументы Оценка и Дата сдачи.
На рисунке А.1 представлена начальная ER – диаграмма.
На рисунке А.2 представлена в виде отношений ER – диаграмма.
Рисунок А.1 – Начальная ER-диаграмма
Рисунок А.2 – Представление сущностей в виде отношений
Все отношения находятся в 1НФ, поскольку свойства всех полей неделимы, и во 2НФ, поскольку все неключевые поля однозначно определяются ключевыми полями. Однако есть поля, функционально зависящие от неключевых полей. Эти зависимости обозначены стрелочками на рисунке А.2. Ниже на рисунках А.3 и А.4 показаны результаты приведения этих таблиц к 3НФ (декомпозиции).
Рисунок А.3 – Результат декомпозиции отношения Студенты
Рисунок А.4- Результат декомпозиции таблицы Учебный план
Однако в отношении Учебный план поля Форма отчетности и Кол. часов зависят не только от ключевого поля Код дисциплины, но и от неключевого поля Дисциплина. Выполним повторно декомпозицию отношения Учебный план, разбив его на два новых согласно варианту 2 (см рисунок А.5).
Рисунок А.5 - Результат декомпозиции таблицы Учебный план
Все таблицы теперь приведены к 3НФ.
На основании полученных таблиц создаем схему БД и устанавливаем связи с помощью первичных и вторичных ключей.
Рисунок А.6 - Полная схема БД
Отношения базы данных
Заполнение связанных таблиц начинаем с заполнения главной таблицы.
Т а б л и ц а А.1 – Отношение Группы (фрагмент)
|
Группа (РК) |
Староста |
Эдвайзер |
|
БЭ-09-1 |
Сытник А.Т. |
Калабеков С.С. |
Т а б л и ц а А.2 – Отношение Студенты (фрагмент)
|
Код студента (РК) |
ФИО студента |
Пол |
Телефон студ. |
Адрес студ. |
Группа (FK) |
|
2 |
Иванов И. |
Муж |
325-32-14 |
Мкр 1, д 2 |
БЭ-09-1 |
Т а б л и ц а А.3 – Отношение Кафедры (фрагмент)
|
Кафедра (PK) |
ФИО заведующего |
Телефон каф |
Аудитория |
|
Кибернетика |
Курмангалиев И.Т. |
231-56-45 |
А411 |
Т а б л и ц а А.4 – Отношение Потоки (фрагмент)
|
Поток |
Кол студентов |
|
БЭ-09-1 |
21 |
|
БЭ-09-1,2,3,4 |
90 |
Т а б л и ц а А.5 – Отношение Преподаватели (фрагмент)
|
Код преподавателя (PK) |
ФИО преподавателя |
Должность |
Телефон |
Адрес |
Кафедра (FK) |
|
3 |
Тайцев Л.К. |
Профессор |
255-56-41 |
Мкр 2, д 3, кв 55 |
ТОЭ |
Т а б л и ц а А.6 – Отношение Дисциплины (фрагмент)
|
Дисциплина (РК) |
Форма отчетности |
Кол часов |
|
ТОЭ лаб |
Рубеж |
32 |
|
ТОЭ лек |
Экзамен |
32 |
Т а б л и ц а А.7 – Отношение Учебный план (фрагмент)
|
Код дисциплины (РК) |
Дисциплина |
Код преподавателя |
Поток |
|
2 |
ТОЭ лек |
Тайцев Л.К. |
БЭ-09-1,2,3,4 |
|
5 |
ТОЭ лаб. |
Турова Л.Б. |
БЭ-09-1 |
Т а б л и ц а А.8 – Отношение Ведомость (фрагмент)
|
Студент |
Дисциплина |
Оценка |
Дата |
|
Иванов И. |
ТОЭ лек |
7 |
18.10.2009 |
В таблице Ведомость применена подстановка из главной таблицы Студенты и поставлена подпись Студент для поля Код студента. Для поля Код дисциплины применена подстановка из главной таблицы Дисциплины. Подстановка выполнена с показом дополнительного поля Поток.
Рисунок А.7 - Подстановка
Рисунок А.8 – Свойства поля Код студента отношения Ведомость
Т а б л и ц а А.9 - Перекрестный запрос для определения нагрузки
|
ФИО преподавателя |
Итоговое значение Кол часов |
ТОЭ лаб. |
ТОЭ лек. |
Физика лаб. |
Физика лек. |
|
Тайцев Л.К. |
54 |
22 |
32 |
|
|
|
Теткова П.Р. |
32 |
|
|
|
|
Отчет «Отличники» (фрагмент)
|
Дисциплина |
Форма отчета |
ФИО студента |
Оценка |
Преподаватель |
Эдвайзер |
|
ТОЭ лек. |
Экзамен |
Новикова Н. |
8 |
Тайцев Л.К. |
Серов В.М. |
|
Физика лек. |
Экзамен |
Иванов И. |
9 |
Факов Л.К. |
Калабеков С.С. |
|
Физика лек. |
Экзамен |
Сарсембаев Б |
8 |
Факов Л.К. |
Серов В.М |
Отчет «Зимняя сессия» (фрагмент)
|
Дисциплина |
Форма отчета |
ФИО студента |
Оценка |
Преподаватель |
Эдвайзер |
|
ТОЭ лаб. |
Рубеж |
Лыкова Н |
5 |
Титов Л.Б. |
Калабеков С.С. |
|
ТОЭ лек |
Экзамен |
Новикова Н. |
9 |
Тайцев Л.К |
Калабеков С.С. |
Рисунок А.9- Круговая диаграмма
Отчет «Дисциплины, сданные с 19 по 25 октября»
|
Дисциплина |
ФИО студента |
Группа |
Оценка |
Дата |
|
ТОЭ лаб |
Лыкова Н |
БЭ-09-1 |
5 |
22.10.2009 |
|
Физика лаб. |
Иванов И |
БЭ-09-1 |
8 |
20.10.2009 |
|
Физика лаб. |
Петров П |
БЭ-09-2 |
7 |
19.10.2009 |
Список литературы
1. О. Голицына, Н. Максимов, И. Попов. Базы данных. -М.: “Форум”, 2005.2. С. Робинсон. Microsoft Access 2000. Учебный курс. - СПБ: Питер, 2001.
3. Дейт К.Дж. Введение в системы баз данных. / Перевод с англ. 7-е издание. М.: Вильямс, 2001.4. MS Access. Меню справка. - Примеры баз данных. – Учебная база данных БОРЕЙ.
5. Питер Роб, Карлос Коронел. Системы баз данных: Проектирование, реализация и управление.- Санкт-Петербург: БХВ- Петербург, 2004.
6. Р. Ахоян, А. Горев, С. Макашарипов. Эффективная работа с СУБД. – Санкт-Петербург: Питер, 1997.7. С. В. Глушаков, Д. В. Ломотько. Базы данных: Учебное пособие. -М.:АБФ, 2000.
Содержание
Введение |
3 |
1 Этапы проектирования данных |
4 |
2 Процедура нормализации |
7 |
3 Варианты заданий на РГР |
12 |
Приложение A. Проект базы данных (образец) |
19 |
Список литературы |
25 |