СОДЕРЖАНИЕ

Введение

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

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

1.2. Инфологическое моделирование

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

2.1. Модель «сущность-связь»

2.2. Связи между сущностями

Заключение

Список литературы

Введение

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

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

Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД.

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

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

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

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

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

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

Для работы приемной комиссии была создана программа «Абитуриент АГПК», включающая в себя базу данных в СУБД MSAccess.

Спроектированная база данных содержит полную систему взаимосвязанных сведений о поступающих в колледж.

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

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

Результатом работы программы «Абитуриент АГПК» являются отчеты, формы, запросы, а на более высоком уровне – макросы (описание объединения нескольких заданий, выполняющихся автоматически).

1.2. Инфологическое моделирование

Пусть необходимо построить базу данных, содержащую информацию об учебном процессе текущего семестра:

· списки студентов групп;

· перечень изучаемых предметов;

· преподавательский состав кафедр, обеспечивающих учебный процесс;

· сведения о лекционных и практических занятиях в каждой из групп;

· результаты сдачи экзаменов (зачетов) по каждому из проведенных занятий.

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

· Документы справочной информации . Справочная информация содержится в документах «Список студентов групп», «Список преподавателей кафедр», «Список изучаемых предметов». На рис. 2, 3 приведены формы справочных документов для студентов и преподавателей.

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

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

Список студентов группы № _________

Количество студентов ___________________

Средний балл в группе при поступлении ___________

Рис. 2. Форма документа со списком студентов группы

Список преподавателей кафедры

Название кафедры ____________

Код кафедры ________ Телефон ______

Заведующий ____________

Рис. 3. Форма документа со списком преподавателей кафедры

План проведения занятий в группе

группа №___________ семестр__________ /текущий/

Рис. 4. Форма документа с перечнем занятий по предмету в группе

Экзаменационная ведомость

Название предмета ______________________ Группа ______________

Преподаватель ______________________________

Вид сдачи __________________________ Дата ____________________

Рис. 5. Форма документа-бланка экзаменационной ведомости

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

2.1. Модель «сущность-связь»

Инфологическая модель применяется после словесного описания предметной области. На основании анализа предметной области выделим следующие сущности модели «сущность-связь» («EntityRelationship» - ER-модели): «Абитуриенты», «Специализации», «Факультеты», и изобразим их в виде графических обозначений (прямоугольник, в верхней части которого записано имя сущности, а ниже перечисляются атрибуты, причем ключевые атрибуты помечаются подчеркиванием).

Как любая модель, модель «сущность-связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определенным правилам.

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

Рассмотрим сущности «Кафедра», «Абитуриент», «Преподаватель», «Предмет учебного плана», «Группа».

Определение сущности «Кафедра» в модели ER

Рис. 2. Определение сущности «Абитуриент» в модели ER

Рис. 3. Определение сущности «Преподаватель» в модели ER

Рис. 4. Определение сущности «Дисциплина» в модели ER

Рис.5. Определение сущности «Группа» в модели ER

Реляционная схема базы данных «Учебный процесс» представлена следующими таблицами:

«Группа» – содержит по одной строке для каждой из групп;

«Студенты» – содержит по одной строке для каждого из студентов;

«Кафедра» – содержит по одной строке для каждой из кафедр;

«Преподаватель» – содержит по одной строке для каждого из преподавателей;

«Предмет» – содержит по одной строке для каждого из предметов;

«Учебный план» – содержит по одной строке для каждого вида занятия по каждому предмету отдельного семестра;

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

Все таблицы базы данных «Учебный процесс» находятся в третьей нормальной форме:

· каждый столбец таблицы неделим, и в рамках одной таблицы нет столбцов с одинаковыми по смыслу значениями (1НФ);

· первичные ключи однозначно определяют запись и неизбыточны, все поля каждой из таблиц зависят от ее первичного ключа (2НФ);

· значение любого поля, не входящего в первичный ключ, не зависит от значения другого поля, тоже не входящего в первичный ключ (3НФ).

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

Структура базы данных

2.2. Связи между сущностями

Между сущностями могут быть установлены связи – бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь ). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности

Связь «один-ко-многим» (1:М), один со стороны «Преподаватель» и многие со стороны «Абитуриент»

В разных нотациях мощность связи изображается по-разному. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Связь любого из этих типов может быть обязательной , если в данной связи должен участвовать каждый экземпляр сущности, необязательной – если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. Обязательность связи тоже по-разному обозначается в разных нотациях. Мы снова используем нотацию POWERDESIGNER. Здесь необязательность связи обозначается пустым кружочком на конце связи, а обязательность перпендикулярной линией, перечеркивающей связь. И эта нотация имеет простую интерпретацию. Кружочек означает, что ни один экземпляр не может участвовать в этой связи. А перпендикуляр интерпретируется как то, что, по крайней мере, один экземпляр сущности участвует в этой связи.

Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как в объектно-ориентированных языках программирования, вводится понятие подтипа сущности, то есть сущность может быть представлена в виде двух или более своих подтипов – сущностей , каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности на подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов. Если на уровне анализа не удается выявить полный перечень подтипов, то вводится специальный подтип, называемый условно «Прочие», который в дальнейшем может быть уточнен. В реальных системах бывает достаточно ввести подтипизацию на двух-трех уровнях.

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности – это имя типа, а не конкретного экземпляра.

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

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

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

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

Следует отметить, что для каждой сущности устанавливается свой код – ключевой атрибут, однозначно характеризующий сущность. Например, обычный номер Абитуриента в группе не может выполнять роль ключа, поскольку для каждой группы эти номера могут повторяться. Для преподавателя атрибут Табельный номер нежелательно брать в качестве ключевого, поскольку все-таки возможно изменение табельного номера.

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

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

1. «Абитуриенты» объединены в «Группы» (связь М:1).

2. Работу «Преподавателей» организуют «Кафедры» (связь М:1).

3. «Преподаватели» преподают «Предметы учебного плана» (связь 1:М).

5. «Абитуриенты» сдают «Предметы учебного плана» (связь М:М).

Покажем теперь эти связи между всеми сущностями графически с использованием нотации POWERDESIGNER.

Будем считать для простоты, что все Абитуриенты обязательно объединены в группы.

М 1

Моделирование связи между сущностями «Абитуриент» и «Группа»

Аналогичным образом выглядит связь «Преподаватель» и «Кафедра».Для простоты предлагается считать, что каждый преподаватель обязательно работает на какой-нибудь кафедре.

Моделирование связи между сущностями «Преподаватель» и «Кафедра»

Версия полной ER-модели для базы данных «Учебный процесс».

1

М

1 М 1

Заключение

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

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

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

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

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

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

Список литературы

1. Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.

2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.

3. Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с.

4. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. – 252 с.

5. Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.

6. Мартин Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 1984. – 196 с.

7. Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.

8. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.

9. Ульман Дж. Базы данных на Паскале. – М.: Машиностроение, 1990.–386 с.

10. Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.

11. Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с.