Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

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

Читайте также:
  1. Глава 3. ПРОЕКТИРОВАНИЕ КОНСТРУКЦИИ СКВАЖИНЫ
  2. Если в здании на проектирование указан тип тягача, то по его силе тяги на низшей передаче определяется вместимость ковша скрепера
  3. ЗАДАНИЕ НА ПРОЕКТИРОВАНИЕ
  4. Исследование и проектирование организационных структур управления.
  5. Исходные данные на дипломное проектирование
  6. Концептуальное проектирование базы данных

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

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

Сущность – объект природы, который имеет уникальное имя.

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

Средства, примененные при проектировании инфологической модели.

Для проектирования инфологической модели будем применять диаграммы “сущность - связь” (Entity - Relationship Diagrams). Диаграммы “сущность-связь” (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущность системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами.

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

Отношение – в самом общем виде представляет собой связь между двумя и более сущностями.

 

Произведем описание предметной области, используя определенные выше термины. Определим несколько правил, которыми будем руководствоваться:

- Имя сущности должно быть уникально на уровне описываемой модели;

- Имена атрибутов должны быть уникальны на уровне описываемой модели;

- Связи будем идентифицировать по их назначению;

- Допускается использование атрибутов в нескольких сущностях одновременно;

- Имена сущностей должны, по возможности, нести информацию об описываемых посредством их объектов предметной области;

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

В данном случае у нас будут сущности:

Основные сущности:

1. «Преподаватели»

· Код преподавателя;

· ФИО преподавателя;

· ЦК;

2. «Дисциплины»

· Код;

· Дисциплина;

· Семестр;

· Группа;

· Преподаватели;

· Литература;

3. «Литература»

· Код;

· Наименование дисциплин;

· Количество обучающихся;

· Автор, название;

· Количество (экз);

· Методическое пособие;

· Год издания;

4. «Нагрузка»

· Код предмета;

· Группа/предмет;

· Кол_час_неделю (1 сем);

· Часы_лаб/пр (1 сем);

· Деление_лаб/пр (1 сем);

· Экз/зач (1 сем);

· Экз-часы (1 сем);

· Кол_час_всего (1 сем);

· Кол_часов_неделю (2 сем);

· Деление_лаб/пр (2 сем);

· Часы_лаб/пр (2 сем);

· Экз/зач (2 сем);

· Экз_часы (2 сем);

· Кол_час_всего (2 сем);

· Дата_начала_занятий;

· Дата_оконч_занятий;

5. «КТП»

· Урок;

· Календарные сроки изучения темы;

· Наименование тем;

· Количество часов;

· Вид занятий;

· Учебно-наглядные пособия;

· Задания для студентов;

6. «Распис. Нов.»

· Код;

· Неделя нечет/чет;

· День недели;

· Пара;

· Предмет;

7. «Расписание_неделя»

· Пара;

· Четная/нечетная;

· Понедельник

· Вторник

· Среда

· Четверг

· Пятница

· Суббота

· Воскресенье

8. «Календарь»

· День

· Месяц

· Выходные да/нет

· День недели

· Номер уч. Недели

· Нечетная/четная

Вспомогательные сущности:

1. «чет/нечет неделя»

· Неделя ключевой атрибут

· Нечет/чет

2. «Группа»

· Название специальности

· Группа

3. «ЦК»

· Номер

· Название

Ключевые атрибуты однозначно определяют экземпляр сущности. Например, ключевое поле «Неделя» будет описанием конкретного кода, нечет/четн.,

На ЕR - диаграмме сущность обозначают:

 
 
Название сущности


Предметы во Вкладыш
День Выходныеда/нет Деньнедели

Ключевой атрибут

Между сущностями устанавливается связь. Она может быть между разными сущностями или между сущностями и ей самой, т.е. рекурсивная связь. Рекурсивная связь показывает, как связаны экземпляры сущности между собой.

Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Связь может быть обязательной, если в ней должен участвовать каждый элемент сущности; иначе эта связь будет необязательной. Связь также может быть обязательной с одной стороны и необязательной с другой.

Условные обозначения, примененные при описании отношений.

       
   
 
 


Отношение один к одному обязательное с обеих сторон   Отношение один к одному необязательное с обеих сторон   Отношение один к одному необязательное с одной из сторон и обязательное с другой   Отношение один ко многим обязательное с одной из сторон и необязательное с другой   Отношение многие к одному, необязательное с одной из сторон и обязательное с другой   Отношение многие ко многим необязательное с обеих сторон   Отношение многие ко многим обязательное с обеих сторон  

 

У меня получается 3 инфологические модели, т.к. у меня 3 блока.

Дисциплины
Код Дисциплина Семестр Группа Преподаватели Литература

 

 

ЦК
Номер Название

Литература
Код Наименование дисциплин Количество обучающихся Автор, название Количество (экз) Методическое пособие Год издания

 

 

Группа
Название специальности группа

 

 

Преподаватели
Код преподавателя ФИО преподавателя ЦК

 

 

Рис.2.2.1 Инфологическая модель(ER-диаграмма). Справочная информация

 

Нагрузка
Код предмета Группа/предмет Кол-час_неделю (1сем) Часы_лаб/пр (1 сем)

КТП
Урок Календарные сроки Наименование тем Количество часов Вид Занятий Учебно-наглядное пособие Задание для студента примечание Дисциплина

 

Распис нов
Неделя нечет/чет День недели Пара Предмет

 

 

Рис.2.2.1 Инфологическая модель(ER-диаграмма). Календарно-тематический план, расписание

 

 

Чет/нечет неделя
Неделя нечет/чет

 

Расписание_неделя
Пара Четная/нечетная Понедельник Вторник Среда Четверг Пятница Суббота Воскресенье

 

 

Календарь
День Месяц Выходные да/нет ДеньНед Номер уч нед Нечетная/четная    

 

 

Рис. 2.2.1 Инфологическая модель(ER-диаграмма). Календарь, ежедневник

 

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

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

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


Дата добавления: 2015-07-08; просмотров: 335 | Нарушение авторских прав


Читайте в этой же книге: Введение | Анализ предметной области | Требования по надежности | Разработка запросов | Запрос на обновление | Разработка отчетов | Разработка форм для ввода и вывода информации | Разработка инструкции пользователю | Организационные и технические мероприятия по защите от поражения электрическим током | Программное представление формы |
<== предыдущая страница | следующая страница ==>
Потоки данных| Мною, были созданы таблицы в режиме Конструктора.

mybiblioteka.su - 2015-2024 год. (0.023 сек.)