close

Вход

Забыли?

вход по аккаунту

?

Мехнецова РПЗ БД (2)

код для вставкиСкачать
Минобрнауки РФ
ФГБОУ ВПО Череповецкий государственный университет
Институт информационных технологий
Кафедра ПО ВТ и ИС
Дисциплина: Базы данных
Курсовая работа
Проектирование базы данных "Электронный журнал старосты группы"
Выполнил студент ____ Мехнецова К.А. _____
Группа ___________1ПО-31______
Принял преподаватель ______Селяничев О.Л_____ Отметка о зачете ________________________
Череповец, 2012 г.
Оглавление
Введение..........................................................................................
1. Описание предметной области.......................................................
2. Функциональное назначение........................................................
3. Инфологическое проектирование...................................................
4. Даталогическое проектирование.....................................................
4.1. Нормализация......................................................................
4.1.1. Первая нормальная форма......................................................
4.1.2. Вторая нормальная форма....................................................
4.1.3. Третья нормальная форма.....................................................
5. Логическая модель данных..........................................................
6. Физическая модель данных...............................................................
7. Разработка приложения для работы с базой данных..........................
Заключение ........................................................................................
Список литературы .............................................................................
ПРИЛОЖЕНИЕ 1. Текст программы.....................................................
ПРИЛОЖЕНИЕ 2. Руководство пользователя..........................................
Введение
Базы данных - совокупность данных, организованная по определенным правилам, предусматривающая общие принципы описания, хранения, манипулирования данными, независимыми от прикладных программ.
СУБД - система управления базами данных - совокупность программ, предназначенных для управления БД и возможности получения пользователями необходимой информации из базы. На сегодняшний день существует множество различных систем управления базами данных. Они все используют разные средства и функции, но преимущественно у всех СУБД в основе лежат одинаковые понятия. Поэтому для обобщения этих понятий, приемов и методов на весь класс СУБД, я хотела бы взять программу, входящую в Microsoft Office, Microsoft Access.
Microsoft Access -реляционная СУБД, в которой предусмотрены все необходимые средства для определения и обработки данных, а также управления ими при работе с большим объемом информации.
Студентов в университете окружает большое количество информации, но больше всего информации приходится на долю старосты. И чтобы структурировать этот объем информации, я решила разработать данную программу. Она предназначена для студентов высших и средних учебных заведений и не требует особых знаний, кроме базовых навыков работы на компьютере. Эта программа поможет быстро получить сведенья о студентах данной группы, об их посещаемости занятий, сведения о расписании занятий и экзаменов, список преподавателей и закрепленные за ними дисциплины. Она может быть использована старостами групп, для более удобной работы с необходимой им информацией.
1. Описание предметной области
Предметной областью данной разработки является электронный журнал старосты группы, который выполняет множество различных функций:
- просмотр и добавление информации о студентах данной группы; - просмотр таблицы посещаемости студентов;
- просмотр расписания занятий и экзаменов;
- просмотр списка преподавателей и закрепленных за ними дисциплин.
Пользователями программного продукта являются старосты групп, которые будут заполнять журнал во время учебного года.
2. Функциональное назначение
В программе реализованы следующие функции:
* добавление записи в базу данных;
* удаление записи из базы данных;
* выборка в базе данных по указанным параметрам.
3. Инфологическое проектирование
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Цель этапа инфологического проектирования состоит в получении семантических (концептуальных) моделей, отражающих предметную область и информационные потребности пользователей. Процесс проектирования длительный, он требует обсуждений с заказчиком, со специалистами в предметной области. Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет "читаться" не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД [2].
Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLean) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, "модель сущность-связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность-связь", пли "Entity Relationship", стала фактическим стандартом при инфологическом моделировании баз данных. Общепринятым стало сокращенное название ER-модель, большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели [5].
В качестве инструмента для построения семантических моделей данных на этапе инфологического проектирования как раз и является неформальная модель "Сущность-Связь" (ER-модель - Entity-Relationship). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов[5].
Основными понятиями ER-модели являются сущность, связь и атрибут.
Сущность (объект) - это реальный или представляемый объект предметной области, информация о котором должна сохраняться и быть доступна. Различают такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов, событий, личностей, выступающих как единое целое. Экземпляр сущности относится к конкретной вещи в наборе. В диаграммах ER-модели сущность представляется в виде прямоугольника (в нотации Баркера), содержащего имя сущности [2].
Атрибут - поименованная характеристика сущности, определяющая его свойства и принимающая значения из некоторого множества значений. Каждый атрибут обеспечивается именем, уникальным в пределах сущности [2].
Связь - это поименованная графически изображаемая ассоциация, устанавливаемая между сущностями и представляющая собой абстракцию набора отношений, которые систематически возникают между различными видами предметов в реальном мире. Большинство связей относятся к категории бинарных и имеют место между двумя сущностями [2].
В соответствии с упомянутыми ранее определениями данная область данных будет содержать следующие сущности: студенты, преподаватели, расписание и посещаемость.
Атрибуты сущности "Студенты":
* фамилия;
* имя;
* отчество;
* адрес;
* телефон.
Атрибуты сущности "Преподаватели":
* фамилия;
* имя;
* отчество;
* закрепленная дисциплина.
Атрибуты сущности "Расписание":
* с какой недели;
* по какую неделю;
* день;
* дисциплина;
* пара;
* тип;
* преподаватель;
* кабинет.
Атрибуты сущности "Посещаемость"
* дата;
* дисциплина;
* студент;
* присутствовал;
* отсутствовал (уважительная причина).
Данная структура позволит легко представить все данные в одной таблице.
Каждая сущность будет иметь свой уникальный номер и ряд полей, характеризующих ее.
4. Даталогическое проектирование
Содержанием даталогического проектирования является определение модели данных. Модель данных - это набор соглашений по способам представления сущностей, связей, агрегатов, системы классификации. Кроме этого каждая модель данных определяет особенности выполнения основных операций над данными:
- добавление,
- удаление,
- выборка.
В качестве модели данных была выбрана реляционная модель данных.
Реляционная модель данных - логическая модель данных, строгая формальная теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в реляционных базах данных [7].
Основными достоинствами реляционной модели данных являются: - простота и доступность; - независимость данных;
- гибкость; - возможность непроцедурных запросов. [6]
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. Таблица 1 является ненормализованной и ее необходимо привести к нормальной форме.
Исходя из структуры, описанной ранее, можно сформировать следующую таблицу:
Таблица 1. Ненормализованная таблица "Электронный журнал"
ФИО студентаАдресТелефонДатаДисциплинаПосещаемостьФИО преподавателяПараТипКабинетИванов Иван ИвановичПобеды 144-848921123345601.05.12Базы данныхБылСеляничев О.Л.1Лекция218Петров Петр ПетровичЛенина 109-422-33-4401.05.12Базы данныхБылСеляничев О.Л.1Лекция218Сергеев Сергей СергеевичХимиков 12-4533-44-5501.05.12Базы данныхНе былСеляничев О.Л.1Лекция218Михайлов Михаил МихайловичКрасная 98-455-66-7701.05.12Базы данныхБылСеляничев О.Л.1Лекция218
4.1. Нормализация Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является
фундаментальным в теории нормализации реляционных баз данных. Функциональные зависимости определяют устойчивые отношения между субъектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования.
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей.
4.1.1. Первая нормальная форма
Отношение находится в первой нормальной форме (далее - 1НФ) тогда, когда значение всех атрибутов отношения атомарные.
Наша таблица не удовлетворяет требованиям 1НФ, поскольку ей присущи следующие проблемы:
- ФИО студента, ФИО преподавателя, Адрес и Посещаемость не являются атомарными.
В связи с этим приведем нашу таблицу к 1НФ.
Таблица, удовлетворяющая требованиям первой нормальной формы:
Таблица 2. Журнал
ФамилияИмяОтчествоУлицаДомКвартираТелефонДатаДисциплинаБылНе былИвановИванИвановичПобеды144848921123345601.05.12Базы данных+ПетровПетрПетровичЛенина109422-33-4401.05.12Базы данных+СергеевСергейСергеевичХимиков124533-44-5501.05.12Базы данных-МихайловМихаилМихайловичКрасная98455-66-7701.05.12Базы данных+
Таблица 2. Журнал. Продолжение
Фамилия преподавателяИмя преподавателяОтчество преподавателяПараТипКабинетСеляничевОлегЛеонидович1Лекция218СеляничевОлегЛеонидович1Лекция218СеляничевОлегЛеонидович1Лекция218СеляничевОлегЛеонидович1Лекция218Анализируя полученную таблицу можно выявить следующие недостатки:
- большое количество дублируемых данных
- ухудшение читаемости таблицы
- скорость работы с данными ниже из-за их количества.
Поэтому нормализацию данной таблицы необходимо продолжить, чтобы избежать эти недостатки.
4.1.2. Вторая нормальная форма
Отношение находится во второй нормальной форме тогда и только тогда, когда это отношение находится в 1НФ и каждый неключевой атрибут полностью зависит от первичного ключа.
Для этого разделим таблицу 2 "Журнал" на две таблицы "Студенты" и "Преподаватели".
Таблица 3. Студенты
ФамилияИмяОтчествоУлицаДомКвартираТелефонДатаДисциплинаБылНе былИвановИванИвановичПобеды144848921123345601.05.12Базы данных+ПетровПетрПетровичЛенина109422-33-4401.05.12Базы данных+СергеевСергейСергеевичХимиков124533-44-5501.05.12Базы данных-МихайловМихаилМихайловичКрасная98455-66-7701.05.12Базы данных+
Таблица 4. Преподаватели
Фамилия преподавателяИмя преподавателяОтчество преподавателяДисциплинаДатаПараТипКабинетСеляничевОлегЛеонидовичБазы данных01.05.121Лекция218СеляничевОлегЛеонидовичБазы данных01.05.121Лекция218СеляничевОлегЛеонидовичБазы данных01.05.121Лекция218СеляничевОлегЛеонидовичБазы данных01.05.121Лекция218
Читаемость таблиц улучшилась, но до сих пор сохраняется повторяемость записей для сохранения атомарности. Продолжим нормализацию таблиц дальше.
4.1.3. Третья нормальная форма
Отношение находится в третьей нормальной форме тогда и только тогда, когда это отношение находиться в 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа. В соответствии с данным определением представим таблицу в следующем виде:
Таблица 5. Студенты1 №ФамилияИмяОтчествоУлицаДомКвартираТелефон1ИвановИванИвановичПобеды14484892112334562ПетровПетрПетровичЛенина109422-33-443СергеевСергейСергеевичХимиков124533-44-554МихайловМихаилМихайловичКрасная98455-66-77
Таблица 6. Посещаемость
№ДатаДисциплинаСтудентБылНе был101.05.1211+201.05.1212+301.05.1213_401.05.1214+
Таблица 7. Расписание занятий
№СПоДеньДисциплинаПара Тип ПреподавательКабинет115Пн.1111218225Вт.22222293110Ср.3313221427Чт.4444217
Таблица 8. Расписание экзаменов
№ДатаПара ТипДисциплинаПреподавательКабинет103.04.122111219204.04.123211219305.04.121133221406.04.122233221
Таблица 9. Список преподавателей
№ФамилияИмяОтчество1СеляничевОлегЛеонидович2ТоловиковМихаилИгоревич3СазановаЕлена Владимировна4ШумиловаВикторияВасильевнаТаблица 10. Список дисциплин
№Дисциплина1Базы Данных2Математика3Физика4Иностранный
Таблица 11. Тип пары
№Тип пары1Лекция2Лаб.раб3Практика4Зачет
Таблица 12. Тип экзамена
№Тип пары1Консультация2Экзамен3Пересдача
На практике достижение 3 нормальной формы считается достаточным, так как с получившимися таблицами можно вести полноценную работу - приложение, построенное на их основе, полностью обеспечит работу кассы аэрофлота. Конечно, можно продолжить процесс нормализации дальше (до 4 нормальной формы), но получившиеся таблицы будут более сложными, а связь между атрибутами станет многофункциональной.
5. Логическая модель данных
Логическая модель данных описывает понятия предметной области и их взаимосвязи и является прототипом будущей базы данных. Логическая модель разрабатывается в терминах информационных понятий, но без какой-либо ориентации на конкретную СУБД [2].
Логическую модель представим в виде ER-диаграммы. Основные преимущества ER-моделей:
* наглядность;
* модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
* ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, CA BPwin Data Modeler).
6. Физическая модель данных
Физическая модель данных строится на базе логической модели и описывает данные уже средствами конкретной СУБД.
Отношения, разработанные на стадии логического моделирования, преобразуются в таблицы, атрибуты в столбцы, домены в типы данных, принятые в выбранной конкретной СУБД. Результатом физического моделирования является генерация программного кода базы данных на соответствующем выбранной СУБД диалекте структурированного языка запросов SQL.
7. Разработка приложения для работы с базой данных
Заключение
Список литературы
1. В. Фаронов "Система программирования Delphi" - СПб.: БХВ-Петербург, 2006.
2. Т.С. Карпова. Базы данных: модели, разработка, реализация - СПб.: "Питер", 2002. - 266 с.
3. http://www.ict.edu.ru/ft/002357/lab12.htm - инфологическое проектирование базы данных;
4. http://www.intuit.ru/department/database/dbmdi/7/ - семантические модели, используемые в современных CASE-системах;
5. http://ru.wikipedia.org/wiki/Реляционная модель данных - реляционные модели данных;
6. http://delphiworld.narod.ru/_db_.html - примеры программ для создания БД на Делфи.
1
Документ
Категория
Рефераты
Просмотров
46
Размер файла
161 Кб
Теги
мехнецова, рпз
1/--страниц
Пожаловаться на содержимое документа