Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

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

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

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

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

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

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

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

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

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

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

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

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

Связь между сущностями «Студент» и «Группа» представлена на рис. 7. Будем считать для простоты, что все студенты обязательно объединены в группы.

М

Студент

Группа

1

Рис. 7. Моделирование связи между сущностями «Студент» и «Группа»

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

М 1

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

Кафедра

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

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

Студент

Группа

М 1

1

Дисциплина

М

М

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

Кафедра

1 М 1

Рис. 9. Моделирование связей между сущностями предметной области «Учебный процесс»

Заключение

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

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

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

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

1. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2002. – СПб.: БХВ-СПб., 2003. – 720 с.

2. Виноградова И.А., Грибова Е.А., Зубков В.Г. Практикум на ЭВМ. MS Access: Учебное пособие для студентов заочной (дистанционной) формы обучения. – М.: ГИНФО, 2000. – 124 с.

3. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352 с.

4. Информатика. Базовый курс. /Под ред. С.В.Симоновича. – СПб.: Питер, 1999. – 640 с.

5. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2002. – 304 с.

6. Петров В.Н. Информационные системы. – СПб.: Питер, 2003. – 688 с.

7. Тихомиров Ю.В. MS SQL Server 2000: разработка приложений. – СПб.: БХВ-Петербург, 2000. – 368 с.

Характеристики

Список файлов курсовой работы