Содержание

Введение 3

1 Инфологическое проектирование 5

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

1.2 Анализ информационных задач и круга пользователей системы 5

1.3 Построение инфологической модели 5

2 Выбор СУБД и других инструментальных программных средств 12

3 Определение требований к операционной обстановке, в которой будет функционировать информационная система 13

4 Логическое проектирование БД 14

4.1 Преобразование ER-диаграммы в схему базы данных 14

4.2 Составление и нормализация полученных отношений 17

5 Физическое проектирование базы данных 23

Заключение 24

Приложение 25

Введение

Потоки информации, циркулирующие в мире, который нас окружает, огромны. Во времени они имеют тенденцию к увеличению. Поэтому в любой организации, как большой, так и маленькой, возникает проблема такой организации управления данными, которая обеспечила бы наиболее эффек­тивную работу. Некоторые организации используют для этого шкафы с папками, но большинство предпочитают компьютеризированные способы – базы данных, позволяющие эф­фективно хранить, структурировать и систематизировать большие объемы дан­ных. И уже сегодня без баз данных невозможно представить работу большинства финансовых, промышленных, торговых и прочих организаций. Не будь баз данных, они бы просто захлебнулись в информационной лавине.

Существует много веских причин перевода существующей информации на компьютерную основу. Сейчас стоимость хранения информации в файлах ЭВМ дешевле, чем на бумаге. Базы данных позволяют хранить, структурировать информацию и извлекать оптимальным для пользователя образом. Использование клиент/серверных технологий позволяют сберечь значительные средства, а главное и время для получения необходимой информации, а также упрощают доступ и ведение, поскольку они основываются на комплексной обработке данных и централизации их хранения. Кроме того ЭВМ позволяет хранить любые форматы данных текст, чертежи, данные в рукописной форме, фотографии, записи голоса и т.д.

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

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

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

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

1 Инфологическое проектирование

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

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

1.2 Анализ информационных задач и круга пользователей системы

Информационные задачи БД:

- БД должна отображать сведения о студентах, преподавателях, успеваемости студентов и предметной области;

- должен осуществляться удобный ввод данных в БД;

- возможность нахождения одних данных по другим;

- предоставление пользователям возможности создания запросов и отчетов.

Круг пользователей системы:

- декан факультета;

- персонал деканата;

- преподаватели.

1.3 Построение инфологической модели

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

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

Этап инфологического проектирования начинается с моделирования предметной области. Проектировщик разбивает её на ряд локальных областей, каждая из которых включает в себя информацию, достаточную для обеспечения запросов отдельной группы будущих пользователей или решения отдельной задачи (подзадачи). Каждое локальное представление моделируется отдельно, затем они объединяются. Выбор локального представления зависит от масштабов предметной области. Обычно она разбивается на локальные области таким образом, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6-7 сущностей.

Выделим в данной базе данных следующие сущности: Список студентов, Предметы, Группы и Преподаватели.

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

Сущность «Предметы» содержит информацию о названии предмета и семестре.

Сущность «Группа» будет содержать аббревиатуру, Код-специальности, Код_факультета, Код_группы.

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

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

Существует три основных класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей - обозначения.

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

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

Характеристическая сущность (характеристика) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства. Например, муж может иметь несколько жен, книга – несколько характеристик переиздания (исправленное, дополненное, переработанное, ...) и т.д. Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж.

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

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

Определил классы для данных сущностей. Стержневыми сущностями будут являться: Предметы, Список студентов, Группа и Преподаватели, так как эти сущности, согласно из определения, имеют независимое существование, хотя некоторые из них могут обозначать другие сущности. Ассоциациями в нашей базе данных будет одна сущность – «Сессионная аттестация». Эта сущность имеет связь вида «многие ко многим». Подклассом ассоциативных сущностей является оступавшиеся сущности. Это «Дополнительные сведения», «Факультеты» и «Специальности». Объединяя все вышеизложенное составим модель базы данных без описания ее атрибутов.

Рисунок 1 – Инфологическая модель БД «Деканата» в виде ЕR-диаграммы, без атрибутов и типов отношений.

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

Сущность «Список студентов» можно характеризовать следующим набором аббревиатур: Номер зачетной книжки – указывается индивидуальный номер зачетной книжки студента, Фамилия – указывается фамилия студента, Имя – указывается имя студента, Отчество – указывается отчество студента, Пол – здесь указывается принадлежность к полу студента или студентки, Подгруппа – указывается подгруппа студента, Курс – указывается курс студента, Форма обучения – указывается форма обучения, Дата рождения – указывается день, месяц и год рождения студента. Так же, как и в предыдущем случае, для однозначного определения комплектующего элемента вводится ключевое поле Код_зачетной книжки.

Сущность «Группа» содержит четыре атрибута: Аббревиатуру, Код_специальности, Код_факультета. Также имеется поле Код_группы, хранящее название аббревиатуру самой группы, но вэтом поле хранится только индекс, а сама аббревиатура подставляется из связанной таблицы «Список студентов». Сущность «Группа » связана с Сущностью «Список студентов» связью один ко многим.

Сущность «Преподаватели» имеет следующие атрибуты: Код_преподавателя, Фамилия – здесь записывается полная фамилия преподавателя, Имя – вносится имя преподавателя, Отчество – здесь вносится отчество данного преподавателя, Ученая степень – указывается ученая степень преподавателя, Дата рождения – указывается дата его рождения: число, месяц и год, Пол – указывается пол данного преподавателя. В данной сущности поле Код_преподавателя хранит только индекс, а сама фамилия подставляется из сущности «Сессионная успеваемость». Сущность «Преподаватели» связана с сущностью «Сессионная успеваемость» связью один ко многим.

Сущность «Сессионная успеваемость» содержит четыре атрибута: Код_зачетной книжки – здесь указывается индивидуальный номер зачетной книжки студента, Код_предмета – указывается полное название предмета, Код_преподавателя – указывается только фамилия преподавателя, который ведет данный предмет, и Оценка – здесь проставляется оценка студента, полученная по данному предмету.

Сущность «Специальности» включает в себя четыре атрибута: Аббревиатура – указывается аббревиатура специальности, Полное название – здесь указывается полное название специальности, Код_факультета – здесь указывается аббревиатура факультета, Код_специальности – хранящее плное название специальности, но в этом поле хранится только инжекс, а само название специальности подставляется из связанной таблицы «Группы». Таблица «Специальности» связана с таблицей «Группы» отношением вида один ко многим.

Сущность «Факультеты» содержит в себе следующие атрибуты: Аббревиатура – здесь указывается аббревиатура факультета, Полное название – указывается полное название факультета, и Код_факультета. Таблица «Факультеты» связана с таблицей «Группы» связью один ко многим.

Сущность «Дополнительные сведения» содержит следующие атрибуты: Город – указывается город «Преподаватели», в котором проживает студент, Адрес – указывается адрес студента, а именно, его улица, номер дома и номер квартиры, № телефона – указывается номер домашнего телефона, если токовой существует, Код_зачетной книжки – указывается индивидуальный номер зачетной книжки студента.

На основании вышеизложенного построим полную инфологическую модель базы данных «Деканата» и изобразим ее в виде ER – диаграммы.

В ER – диаграммах «Сущность-связь» сущности изображаются помеченными прямоугольниками, ассоциации – помеченными ромбами или шестиугольниками, атрибуты – помеченными овалами, а связи между ними – ненаправленными ребрами (линиями, соединяющими геометрические фигуры), над которыми может проставляться степень связи (1 или буква, замещающая слово “много”) и необходимое пояснение.

Рисунок 2 – ER-диаграмма «сущность-связь» БД «Деканат»

2 Выбор субд и других инструментальных программных средств

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

Самыми популярными СУБД на сегодняшний день являются: «1С-предприятия», «Microsoft Access», «Lotus Approach», «Delphi» и т.д.

На многих крупных предприятиях все базы данных реализованы в СУБД «1С предприятие». Эта система управления базами данных имеет то преимущество, что все документы, составленные в ней имеют общий стандарт и могут использоваться для различных отчетностей. Недостаток «1С предприятия» заключается в том, что проектирование новой конфигурации невозможно без знания встроенного языка программирования.

Преимущество СУБД «Delphi» в том, что, создавая базу данных в этом продукте, можно учесть все нюансы фирмы, для которой создается база. Ведь Borland Delphi, по сути, предназначена не только для создания баз данных, а для создания любых приложений. А недостаток в том, что нужно знать язык программирования Турбо Паскаль.

СУБД Microsoft Access – имеет в своем распоряжении более простые средства создания баз данных. Небольшую базу данных можно создать всего лишь при помощи мастеров. Access – это самая популярная сегодня система управления базами данных. Эта СУБД легко доступна, так как она входит в комплект поставки пакета приложений Microsoft Office. СУБД Access 2002 для работы с данными использует процессор баз данных Microsoft Jet 4.0, объекты доступа к данным и средства быстрого построения интерфейса — конструктор форм. Для получения распечаток используются конструкторы отчетов. Автоматизация рутинных операций может быть выполнена с помощью макрокоманд. На тот случай, когда не хватает функциональности визуальных средств, пользователи Access могут обратиться к созданию процедур и функций. Несмотря на свою ориентированность на конечного пользователя, в Access присутствует язык программирования Visual Basic for Application, который позволяет создавать массивы, свои типы данных, вызывать DLL-функции, с помощью OLE Automation контролировать работу приложений, которые могут функционировать как OLE-серверы. MS Access из всех рассматриваемых средств разработки имеет, пожалуй, самый богатый набор визуальных средств.При создании многих объектов и элементов управления в Access предоставляется несколько возможностей реализации поставленной задачи.

Для создания БД «Деканат» используется Access.

3 Определение требований к операционной обстановке, в которой будет функционировать информационная система

Данная база будет реализована в приложении Microsoft Office - Microsof Access.

В институте, университете или в другом учебном заведении, где имеется деканат, в котором предполагается использовать данную базу данных, будет находиться несколько компьютеров, для этого должна быть установлена сетевая операционная система, такая как Windows NT или Windows 2000. Для быстрого функционирования базы данных каждый из компьютеров должен иметь хорошее аппаратное обеспечение. Также на компьютерах должен быть установлен пакет Microsoft Office 2002, с русской версией Microsoft Access.

Спроектированная незаполненная база данных (таблицы, формы, стандартные запросы, отчеты), то есть ее структура занимает 3,95 Мб памяти на жестком диске. Запись в таблице Дополнительные сведения занимает 64 Байт. Запись в таблице Факультеты занимает 45 Байт. Запись в таблице Специальности занимает 70 Байт. Запись в таблице Группы занимает 60 Байт. Запись в таблице Список студентов занимает 268 Байт. Запись в таблице Сессионная успеваемость 83 Байт. Запись в таблице Предметы занимает 35 Байт. Запись в таблице Преподаватели занимает 138 Байт. В основном будут заполняться таблицы: Список студентов, Дополнительные сведения, Сессионная успеваемость, Остальные таблицы будут заполняться не часто. Допустим, при внесении в каждую из этих таблиц 100 записей БД увеличится на 41,5 Кбайт.