База данных электронный журнал

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

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

Логическое проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, разработке алгоритмов обработки информации, создании форм для ввода данных в базе данных и решения ряда других задач.

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

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

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

Выполнение правил нормализации обычно приводит к разбиению первичной таблицы на несколько таблиц с меньшим количеством столбцов. Так как при создании проекта таблицы были приведены к третьей НФ, то имеет смысл кратко рассмотреть суть первых трех НФ.

Таблица будет соответствовать 1 НФ, если все её атрибуты будут иметь неделимые значения. Соответствие 2 НФ заключается в соответствии первой НФ и полной функциональной зависимости каждого не ключевого атрибута от его составного ключа. 3 НФ заключается в соответствии 2 НФ и не транзитивной зависимости каждого не ключевого атрибута от первичного ключа.

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

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

• 1. Сбор информации об объектах решаемой задачи в рамках одной таблицы (одного отношения) и последующая декомпозиция её на несколько взаимосвязанных таблиц на основе процедуры нормализации отношений.
• 2. Формулирование знаний о системе (определение типов исходных данных и их взаимосвязей).
• 3. Структурирование информации для использования в информационной системе в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

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

• 1. Данные об учениках;
• 2. Данные о преподавателях;
• 3. Данные об успеваемости (оценках);
• 4. Перечень учебных дисциплин (предметов);
• 5. Данные о пользователях программы.

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

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

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

Таблица Логическая структура таблиц базы данных

Общие сведения о проектировании базы данных и разборка приложений для взаимодействия с БД. Разработка проекта клиентского приложения "Электронный классный журнал" с помощью языка программирования Delphi 7. Просмотр и изменение информации базы данных.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской федерации

Государственное образовательное учреждение среднего специального образования

Московский государственный колледж информационных технологий

Специальность 230105 «Программное обеспечение вычислительной техники и автоматизированных систем»

по дисциплине «Разработка и эксплуатация удаленных баз данных»

на тему: «Электронный классный журнал»

1.1 Цель разработки

1.2 Обоснование выбора среды разработки приложения

1.3 Характеристика среды разработки приложения

1.4 Методика создания приложений для баз данных

2. Специальная часть

2.1 Постановка задачи

2.2 Логическая схема БД

2.3 Описание структуры БД

2.4 Разработка приложения.

2.4.1 Схема функционирования приложения

2.4.2 Разработка Интерфейса пользователя

2.5 Описание Процесса отладки приложения

2.6 Инструкция пользователю

Данный курсовой проект посвящен разработке «Электронного классного журнала»(ЭКЖ).

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

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

· Проектирование базы данных (БД);

· Разработка приложения для взаимодействия с БД.

Приложение представляет собой клиент-серверную систему:

· серверная часть: MS SQL Server

· клиентская — Borland Delphi 7

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

«Электронный классный журнал» позволяет просматривать, а также изменять оценки студентов той или иной группы по определенному предмету по заданной дате.

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

1.1 Цель разработки

Цель разработки заключается в написании приложения БД с помощью Delphi 7 и создание базы данных с помощью MS SQL Server, программы контроля знаний учащихся согласно техническому заданию ГОУ СПО МГКИТ.

1.2 Обоснование выбора среды разработки приложения

Средства разработки MS SQL Server и Borland Delphi выбраны так как идеально подходят для выполнения задания и были изучены на протяжении курса образовательного учреждения.

1.3 Характеристика среды разработки приложения

Delphi (Дельфи) — среда разработки, использует язык программирования Delphi (начиная с 7 версии язык в среде именуется Delphi, ранее — Object Pascal), разработанный фирмой Borland и изначально реализованный в её пакете Borland Delphi, от которого и получил в 2003 году своё нынешнее название. Object Pascal, по сути является наследником языка Pascal с объектно-ориентированными расширениями.

Delphi — оптимальный инструмент для создания приложений для баз данных.

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

Особенности семейства Delphi 7:

· Среда быстрой разработки приложений, в которой интегрированы средства моделирования разработки и развертывания приложений электронной коммерции и Web-сервисов.

· Поддержка языков программирования для Win32 (Delphi и C/C++) и для .NET (Delphi и C#) в единой среде разработки, что позволяет упростить сопровождение и создание новых приложений Win32 и более легко освоить технологии .NET;

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

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

Microsoft SQL Server 2000 — это законченное предложение в области баз данных и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных.

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

В сервер SQL Server 2000 включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения.

Кроме того, SQL Server 2000 полностью использует все возможности операционной системы Windows, включая поддержку до 32 процессоров и 64 ГБ ОЗУ.

1.4 Методика создания приложений для баз данных

*Получение задания на курсовое проектирование.

* Изучение методических указаний курсовому проектированию.

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

* Составление алгоритма программы.

* Разработка технического задания на создание ЭКЖ.

* Разработка первой версии ЭКЖ.

* Опытная эксплуатация ЭКЖ.

* Разработка полнофункциональной версии ЭКЖ.

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

* Проведение испытаний и подготовка ЭКЖ к эксплуатации.

* Оформление пояснительной записки Курсовой Работы.

* Сдача Курсовой Работы на проверку.

Определение требований к системе:

* определение требований к техническому и программному обеспечению

Сбор и анализ требований от пользователей.

Проектирование базы данных:

· Концептуальная модель данных — записанные знания о физических и логических объектах реального мира (люди, компоненты инфраструктуры, наряды на работу, договора, соглашения и т. д.), которыми необходимо управлять наиболее рациональным образом.

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

· Физическая модель данных — способ хранения данных в конкретной СУБД. Строится на основе логической модели данных.

Реализация приложения для работы с базой данных.

Программа состоит из графической и программной части.

Графическая часть — интерфейс, то что видит пользователь.

Программная часть это процедуры обработки событий.

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

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

2. Специальная часть

2.1 Постановки задачи

Средствами MS SQL SERVER и DELPHI создать приложение, позволяющее осуществлять:

1) подключение БД определенного типа(как на локальном, так и на сетевом компьютере);

2) вывод на экран поисковой панели;

3) вывод на экран списка всех студентов и групп;

4) вывод на экран список студентов только одной группы;

5) вывод на экран информации об оценках по конкретному стеденту;

6) вывод на экран ведомости об успеваемости за отчетный период(год, день);

7) ввод оценки для студента по определенному предмету;

8) добавление студента в группу под личным(автоматическим) номером в списке;

2.2 Логическая схема БД

Физическая схема БД.

2.3 Описание структуры БД.

В спроектированной согласно заданию техническому заданию базе данных получилось 3 таблицы: Анкета, Успеваемость, Предмет.

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4

Минобрнауки РФ

ФГБОУ ВПО Череповецкий государственный университет

Институт информационных технологий

Кафедра ПО ВТ и ИС

Дисциплина: Базы данных

«Электронный журнал старосты группы»

Выполнил студент ____ _____

Принял преподаватель ______ Л_____

Отметка о зачете ________________________

Череповец, 2012 г.

1. Описание предметной области…………………………………………. ….4

2. Функциональное назначение…………………………………………………4

3. Инфологическое проектирование…………………………………………4-6

4. Даталогическое проектирование…………………………………. ………...6

4.1. Ненормализованная таблица…………………………………………….7

4.1. Первая нормальная форма………………...………………….…….….8-9

4.2. Вторая нормальная форма…………………………. ……………….9-10

4.3. Третья нормальная форма………………………...…. …………….11-14

5. Логическая модель данных………. ……………………………………….14

6. Физическая модель данных…………………………………. 15

7. Разработка приложения для работы с базой данных…………………15-16

ПРИЛОЖЕНИЕ 1. Текст программы…………………………………………19-30

ПРИЛОЖЕНИЕ 2. Руководство пользователя………………………………31-43

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

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

На сегодняшний день существует множество различных систем управления базами данных. Они все используют разные средства и функции, но преимущественно у всех СУБД в основе лежат одинаковые понятия. Поэтому для обобщения этих понятий, приемов и методов на весь класс СУБД, была взята программа, входящую в Microsoft Office: 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].

В соответствии с упомянутыми ранее определениями данная область данных будет содержать следующие сущности: студенты, преподаватели и расписание.