СОДЕРЖАНИЕ
Введение
1. Анализ предметной области
1.1. Описание предметной области
1.2. Инфологическоемоделирование
2. Инфологическоепроектирование
2.1. Модель «сущность-связь»
2.2. Связи между сущностями
Заключение
Списоклитературы
Введение
Процесс проектирования БДна основе принципов нормализации представляет собой последовательностьпереходов от неформального словесного описания информационной структурыпредметной области к формализованному описанию объектов предметной области втерминах некоторой модели.
Инфологическая модельприменяется на втором этапе проектирования БД, то есть после словесногоописания предметной области. Процесс проектирования длительный и требуетобсуждений с заказчиком и со специалистами в предметной области. Наконец, приразработке серьезных корпоративных информационных систем проект базы данныхявляется тем фундаментом, на котором строится вся система в целом, и вопрос овозможном кредитовании часто решается экспертами банка на основании именнограмотно сделанного инфологического проекта БД. Следовательно, инфологическаямодель должна включать такое формализованное описание предметной области,которое легко будет «читаться» не только специалистами по базам данных. И этоописание должно быть настолько емким, чтобы можно было оценить глубину икорректность проработки проекта БД, и конечно, оно не должно быть привязано кконкретной СУБД. Выбор СУБД – это отдельная задача, для корректного ее решениянеобходимо иметь проект, который не привязан ни к какой конкретной СУБД.
Инфологическоепроектирование прежде всего связано с попыткой представления семантикипредметной области в модели БД.
Целью данной курсовойработы является систематизация, накопление и закрепление знаний о построенииинфологической модели и построение инфологической модели базы данных «Абитуриент».
Цель проекта: созданиеподсистемы, отвечающей за хранение и обработку личных дел абитуриентов,поступающих в университет согласно правилам приема абитуриентов.
1.Анализ предметной области 1.1.Описание предметной области
В базе«Абитуриент» отражаются личные данные абитуриентов в которых хранятсяданные об аттестате, сведения о сдаче вступительных экзаменах, форма обучения атакже некоторые дополнительные данные (информация о поданных заявлениях,сведения о родителях, воинский учет, увлечения). Формируются списки назачисление согласно результатам вступительных экзаменов.
Широкое применениекомпьютерных технологий в учебном процессе выдвинуло перед работниками приемнойкомиссии АГПК задачу автоматизировать работу приемной комиссии от моментазаполнения личной карточки абитуриента до выполнения различного рода отчетов.
Для работы приемнойкомиссии была создана программа «Абитуриент АГПК», включающая в себя базу данныхв СУБД MS Access.
Спроектированная базаданных содержит полную систему взаимосвязанных сведений о поступающих вколледж.
Программа «Абитуриент АГПК»основана на реляционной модели управления БД, т.е. каждая запись в БД содержитинформацию, относящуюся к одному конкретному абитуриенту. Разработкапользовательского интерфейса программы «Абитуриент АГПК» делается для созданиядостаточно реальных форм и отчетов, с возможностью переключения в режимпредварительного просмотра, что позволяет легко продемонстрировать пользователювнешний вид приложений.
Для связи таблицсоздаётся ключевое поле, которое позволяет закрепить за абитуриентом выбраннуюим специальность, не вводя повторяющиеся данные, а по одному коду или символуобратиться к нужной таблице и прочесть из нее данные. Для эффективного поискаданных используют индексы, которые незамедлительно позволяют отыскать нужногонам абитуриента из общего списка.
Результатом работыпрограммы «Абитуриент АГПК» являются отчеты, формы, запросы, а на более высокомуровне – макросы (описание объединения нескольких заданий, выполняющихсяавтоматически).1.2. Инфологическое моделирование
Пусть необходимопостроить базу данных, содержащую информацию об учебном процессе текущегосеместра:
· списки студентовгрупп;
· переченьизучаемых предметов;
· преподавательскийсостав кафедр, обеспечивающих учебный процесс;
· сведения олекционных и практических занятиях в каждой из групп;
· результаты сдачиэкзаменов (зачетов) по каждому из проведенных занятий.
В результате анализапредметной области выявляются документы – источники данных для создания базыданных.
· Документысправочной информации.Справочная информация содержится в документах «Список студентов групп», «Списокпреподавателей кафедр», «Список изучаемых предметов». На рис. 2, 3 приведеныформы справочных документов для студентов и преподавателей.
· Документыучетной информации.Учетная информация про учебному процессу может быть представлена в планахпроведения занятий в группах на текущий семестр, содержащих перечень лекционныхи практических занятий по предметам (рис. 4), а также в заполненныхэкзаменационных ведомостях (рис. 5).
Особо отметим, чтодокументы предметной области не только дают возможность выявить структуруданных, но и являются основой для разработки форм ввода/вывода, отчетов дляпечати документов.
Список студентовгруппы № _________Номер студента Фамилия И.О. Год рождения Адрес
Балл
при поступлении
Количество студентов___________________
Средний балл в группе припоступлении ___________
Рис. 2. Форма документа со списком студентовгруппы
Список преподавателейкафедры
Название кафедры____________
Код кафедры ________Телефон ______
Заведующий ____________Таб. номер Фамилия И. О. Уч. степень Уч. звание
Рис. 3. Форма документа со спискомпреподавателей кафедры
План проведениязанятий в группе
группа №___________ семестр__________/текущий/Название предмета Код предмета ФИО преподавателя Таб. номер преподавателя Вид занятия Часы
Рис. 4. Форма документа с перечнем занятийпо предмету в группе
Экзаменационнаяведомость
Название предмета______________________ Группа ______________
Преподаватель______________________________
Вид сдачи__________________________ Дата ____________________№ п/п
Фамилия И.О.
студента Оценка Подпись преподавателя
Рис. 5. Форма документа-бланкаэкзаменационной ведомости
2.Инфологическое проектирование2.1. Модель «сущность-связь»
Инфологическая модельприменяется после словесного описания предметной области. На основании анализапредметной области выделим следующие сущности модели «сущность-связь» («Entity Relationship» — ER-модели): «Абитуриенты», «Специализации», «Факультеты», иизобразим их в виде графических обозначений (прямоугольник, в верхней частикоторого записано имя сущности, а ниже перечисляются атрибуты, причем ключевыеатрибуты помечаются подчеркиванием).
Абитуриенты
Код абитуриента ФИО Номер личного дела Награды Потребность в общежитии Стаж работы
Специализации
Код специализации Наименование Кафедра Количество мест
Факультеты
Код факультета Название
Как любая модель, модель«сущность-связь» имеет несколько базовых понятий, которые образуют исходныекирпичики, из которых строятся уже более сложные объекты по заранееопределенным правилам.
Сущность, с помощью которой моделируетсякласс однотипных объектов. Сущность имеет имя, уникальное в пределахмоделируемой системы. Так как сущность соответствует некоторому классуоднотипных объектов, то предполагается, что в системе существует множествоэкземпляров данной сущности. Объект, которому соответствует понятие сущности,имеет свой набор атрибутов – характеристик, определяющих свойстваданного представителя класса. При этом набор атрибутов должен быть таким, чтобыможно было различать конкретные экземпляры сущности.
Рассмотрим сущности«Кафедра», «Абитуриент», «Преподаватель», «Предмет учебного плана», «Группа».
/>
Определение сущности«Кафедра» в модели ER
/>
Рис. 2. Определениесущности «Абитуриент» в модели ER
/> /> /> /> /> /> /> /> /> /> /> /> /> /> /> />
Рис. 3. Определениесущности «Преподаватель» в модели ER/> /> /> /> /> /> /> /> /> /> /> /> /> /> /> />
Рис. 4. Определениесущности «Дисциплина» в модели ER
/>
Рис.5. Определениесущности «Группа» в модели ER
Реляционная схема базыданных «Учебный процесс» представлена следующими таблицами:
«Группа» – содержит поодной строке для каждой из групп;
«Студенты» – содержит поодной строке для каждого из студентов;
«Кафедра» – содержит поодной строке для каждой из кафедр;
«Преподаватель» –содержит по одной строке для каждого из преподавателей;
«Предмет» – содержит поодной строке для каждого из предметов;
«Учебный план» – содержитпо одной строке для каждого вида занятия по каждому предмету отдельногосеместра;
«Успеваемость» – содержитпо одной строке для каждого результата сдачи отдельным студентом отдельнойдисциплины.
Все таблицы базы данных«Учебный процесс» находятся в третьей нормальной форме:
· каждый столбецтаблицы неделим, и в рамках одной таблицы нет столбцов с одинаковыми по смыслузначениями (1НФ);
· первичные ключиоднозначно определяют запись и неизбыточны, все поля каждой из таблиц зависятот ее первичного ключа (2НФ);
· значение любогополя, не входящего в первичный ключ, не зависит от значения другого поля, тожене входящего в первичный ключ (3НФ).
В графической формеизображены перечисленные таблицы, их столбцы, первичные и внешние ключи.Задание первичных и внешних ключей сопровождается построением дополнительныхструктур – индексов, обеспечивающих быстрый доступ к данным через значениеключа.
/>
Структура базы данных2.2. Связи между сущностями
Между сущностями могутбыть установлены связи – бинарные ассоциации, показывающие, какимобразом сущности соотносятся или взаимодействуют между собой. Связь можетсуществовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивнаясвязь). Она показывает, как связаны экземпляры сущностей между собой. Еслисвязь устанавливается между двумя сущностями, то она определяет взаимосвязьмежду экземплярами одной и другой сущности
/>
Связь «один-ко-многим»(1: М), один со стороны «Преподаватель» и многие со стороны «Абитуриент»
В разных нотацияхмощность связи изображается по-разному. Между двумя сущностями может бытьзадано сколько угодно связей с разными смысловыми нагрузками. Связь любого изэтих типов может быть обязательной, если в данной связи долженучаствовать каждый экземпляр сущности, необязательной – если не каждыйэкземпляр сущности должен участвовать в данной связи. При этом связь может бытьобязательной с одной стороны и необязательной с другой стороны.Обязательность связи тоже по-разному обозначается в разных нотациях. Мы сноваиспользуем нотацию POWER DESIGNER. Здесь необязательность связиобозначается пустым кружочком на конце связи, а обязательность перпендикулярнойлинией, перечеркивающей связь. И эта нотация имеет простую интерпретацию.Кружочек означает, что ни один экземпляр не может участвовать в этой связи. Аперпендикуляр интерпретируется как то, что, по крайней мере, один экземплярсущности участвует в этой связи.
Кроме того, в ER-модели допускается принципкатегоризации сущностей. Это значит, что, как в объектно-ориентированных языкахпрограммирования, вводится понятие подтипа сущности, то есть сущность можетбыть представлена в виде двух или более своих подтипов – сущностей,каждая из которых может иметь общие атрибуты и отношения и/или атрибуты иотношения, которые определяются однажды на верхнем уровне и наследуются нанижнем уровне. Все подтипы одной сущности рассматриваются каквзаимоисключающие, и при разделении сущности на подтипы она должна бытьпредставлена в виде полного набора взаимоисключающих подтипов. Если на уровнеанализа не удается выявить полный перечень подтипов, то вводится специальныйподтип, называемый условно «Прочие», который в дальнейшем может быть уточнен. Вреальных системах бывает достаточно ввести подтипизацию на двух-трех уровнях.
Сущность имеет имя,уникальное в пределах модели. При этом имя сущности – это имя типа, а неконкретного экземпляра.
Сущности подразделяютсяна сильные и слабые. Сущность является слабой, если ее существование зависит отдругой сущности – сильной по отношению к ней.
Сущность может бытьрасщеплена на два или более взаимоисключающих подтипов, каждый изкоторых включает общие атрибуты и/или связи. Эти общие атрибуты и/или связиявно определяются один раз на более высоком уровне. В подтипах могутопределяться собственные атрибуты и/или связи. В принципе выделение подтиповможет продолжаться на более низких уровнях, но в большинстве случаевоказывается достаточно двух-трех уровней.
Сущность, на основекоторой определяются подтипы, называется супертипом. Подтипы должныобразовывать полное множество, то есть любой экземпляр супертипа долженотноситься к некоторому подтипу. Иногда для полноты множества надо определятьдополнительный подтип, например, «Прочие».
Представим предметнуюобласть «Учебный процесс» как взаимодействие следующих сущностей: каждый «Абитуриент»сдает экзамен или зачет по некоторому «Предмету» согласно учебному плану. Вучебном процессе участвует «Преподаватель», который осуществляет чтениеучебного курса и контроль знаний «Абитуриента». В учебном процессе такжеучаствует «Кафедра», которая организовывает работу «Преподавателя». Обучение «Абитуриента»ведется в «Группе» совместно с его одногруппниками.
Следует отметить, что длякаждой сущности устанавливается свой код – ключевой атрибут, однозначнохарактеризующий сущность. Например, обычный номер Абитуриента в группе не можетвыполнять роль ключа, поскольку для каждой группы эти номера могут повторяться.Для преподавателя атрибут Табельный номер нежелательно брать в качествеключевого, поскольку все-таки возможно изменение табельного номера.
Для реализациидополнительных функций базы может потребоваться введение дополнительныхатрибутов, например, номера зачетной книжки и домашнего телефона Абитуриента,домашнего адреса и домашнего телефона преподавателя, должности преподавателя,рабочей программы, даты сдачи экзамена (зачета) и т.д.
Будем считать дляпростоты все связи обязательными. Между выделенными сущностями можно выделить,например, следующие связи:
1. «Абитуриенты»объединены в «Группы» (связь М:1).
2. Работу«Преподавателей» организуют «Кафедры» (связь М:1).
3. «Преподаватели»преподают «Предметы учебного плана» (связь 1: М).
5. «Абитуриенты» сдают«Предметы учебного плана» (связь М: М).
Покажем теперь эти связимежду всеми сущностями графически с использованием нотации POWER DESIGNER.
Будем считать дляпростоты, что все Абитуриенты обязательно объединены в группы./> /> /> /> />
Абитуриент
Группа
/> М 1/> /> /> /> /> /> />
Моделирование связи междусущностями «Абитуриент» и «Группа»
Аналогичным образомвыглядит связь «Преподаватель» и «Кафедра».Для простоты предлагается считать,что каждый преподаватель обязательно работает на какой-нибудь кафедре.
Кафедра
Преподаватель /> М 1/> /> /> /> /> /> />
Моделирование связи междусущностями «Преподаватель» и «Кафедра»
Версия полной ER-модели для базы данных «Учебныйпроцесс».
Группа />
Абитуриент М 1/> /> /> /> /> /> /> /> /> /> /> /> />
/> 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 с.