Лр 1-2. Лабораторная работа 1.2. Лабораторная работа 1 Информационное моделирование. Разработка инфологической модели предметной области

Название	Лабораторная работа 1 Информационное моделирование. Разработка инфологической модели предметной области
Анкор	Лр 1-2
Дата	05.11.2022
Размер	251.77 Kb.
Формат файла
Имя файла	Лабораторная работа 1.2.docx
Тип	Лабораторная работа #771218

Лабораторная работа 1

Информационное моделирование. Разработка инфологической модели предметной области

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

Информационное моделирование

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

Процесс информационного моделирования состоит из (см.рис):

сбора данных;
составления частных ЛПП (Локальное пользовательское представление);
унификации пересекающихся эпизодов;
составления ГПП (Глобальное пользовательское представление;
формирования модели предметной области (инфологическое проектирование);
составления схемы с учетом используемого СУБД (концептуальное проектирование);
физического проектирования.

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

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

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

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

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

Какими же средствами воспользоваться для составления инфологического описания предметной области? На этот вопрос нет однозначного ответа. Существует несколько методик, и соответственно применяются разные инструментальные средства. Составляемая модель должна быть проста, наглядна, содержать все сведения для дальнейших этапов проектирования, легко преобразовываться в модели баз данных для распространенных СУБД. Исходя из этих требований, в описываемой методике проектирования используется модель, названная «сущность-связь» (или «объекты-связи»).

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

Сущность - представление (абстракция) реально существующего объекта, процесса или явления. Наименование сущности должно быть уникально во всей модели.

Тип сущности - определяет набор однородных объектов.

Экземпляр сущности - конкретный объект из этого набора.

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

Атрибут - свойство сущности (объекта). Его имя должно быть уникально в рамках одной сущности.

Экземпляр атрибута - конкретное значение свойства.

Например: сущность «Ученик» определяется атрибутами: «Фамилия ученика», «Класс» и т.п. То есть для каждого конкретного ученика (экземпляра сущности) мы должны определить экземпляры атрибутов (их конкретные значения). Продолжим с нашим примером: экземпляр сущности «Ученик» Ваня Иванов имеет экземпляр атрибута «Фамилия ученика» - «Иванов» и экземпляр атрибута «Класс» - «8А».

Идентифицирующий атрибут (идентифицирующая совокупность атрибутов, ИСА) - атрибут (несколько атрибутов), значение которого определяет уникальность экземпляра сущности.

Связь позволяет моделировать отношения между объектами предметной области. Наименование связи должно быть уникально во всей модели.

Теперь попытаемся составить полную инфологическую модель задачи «Школьный журнал». Для этого перечислим те правила, которым должна удовлетворять модель «сущность-связь»:

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

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

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

3. Понятие ключа(Идентифицирующий атрибут)

Идентифицирующий атрибут (идентифицирующая совокупность атрибутов, ИСА) - атрибут (несколько атрибутов), значение которого определяет уникальность экземпляра сущности.

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

4. Реляционная модель данных

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

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

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

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

Введем понятия, необходимые для понимания процесса приведения модели к реляционной схеме.

Отношение - абстракция описываемого объекта как совокупность его свойств. Проводя инфологический этап проектирования, мы говорили об абстракции объектов и приписывали им некоторые свойства. Теперь же, проводя концептуальное проектирование, мы переходим к следующему уровню абстракции. На данном этапе объектов, как таковых, уже не существует. Мы оперируем совокупностью свойств, которые и определяют объект.

Экземпляр отношения - совокупность значений свойств конкретного объекта.

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

Простой атрибут - атрибут, значения которого неделимы.

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

Требования к реляционным моделям

Рациональные варианты концептуальной схемы базы данных должны удовлетворять третьей нормальной форме, а также следующим требованиям:

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

Графическая интерпретация реляционной схемы

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

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

5. Правила нормализации

Нормализация отношений

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

Первая нормальная форма

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

Выполните практическое задание 1 .Приведение отношения к первой нормальной форме.

1. Открыть файл journal.xls. Лист Ученик. Здесь собрана информация об ученике (см. лист Ученик). Анализ таблицы показывает, что в столбце «Родители» и «Место работы» указаны по 2 значения. Кроме того, в столбце адрес слишком много данных. Возможна ситуация, когда РОНО будет интересовать район проживания, при этом конкретная квартира – неинтересна. Из-за неоднозначности значений придется привести таблицу к первой нормальной форме.

2. В таблице скопировать строки и сделать так, чтобы в каждой строке был один родитель.

3. Одновременно нужно создать еще один столбец «Контекст адреса»

4. Получим отношение в первой нормальной форме.

5. Выделим в ней первичный ключ: строки отличаются друг от друга столбцами - «№ билета» и «Фамилии родителей». Зальем желтым цветом.

При приведении отношения «Ученик» к первой нормальной форме мы выполнили два действия:

Атрибут «Адрес» состоит из значений двух свойств. Мы разбили его на атрибуты «Улица» и «Контекст адреса».
Значение атрибута «Фамилии родителей» содержит одно или два значения «Родитель», поэтому мы разделили на несколько значений, что привело к увеличению числа экземпляров отношения.

Полученное отношение не полностью приведено к первой нормальной форме. Придерживаясь правила, следовало бы разбить атрибуты «Фамилия ученика», «Классный руководитель», «Фамилии родителей» на «Фамилия», «Имя», «Отчество» каждый. Однако каждый из исходных атрибутов по сути нашей задачи будет использоваться целиком (т.е. атрибуты можно назвать простыми), и в данном случае формальный подход к процессу нормализации неуместен. Разбивая атрибут «Адрес» на два атрибута, мы также рассуждали неформально. Разработка ведется для районной школы, учащиеся которой живут поблизости, и, следовательно, спектр задействованных улиц невелик. Вполне вероятно возникновение задач, использующих улицу как отдельное значение, но вряд ли возникнут задачи, использующие в качестве параметра номер дома или, тем более, квартиры.

Вторая нормальная форма

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

Проанализируем.

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

Значения в неключевых атрибутах «Улица», «Контекст адреса», «Фамилия ученика», «Специализация класса», «Классный руководитель», «Класс» отношения «Ученик» однозначно определяется значениями одного из атрибутов первичного ключа («Номер ученического билета»). При приведении данного отношения ко второй нормальной форме оно разделяется на два отношения: «Родители» и «Личные данные ученика.

Выполните практическое задание 2 .Приведение отношения ко второй нормальной форме.

1. Открыть файл journal.xls. Лист Ученик.

2. Сделайте еще одну таблицу. Будет 2 таблицы. В одной будет все, что определяется только столбцом «№ билета», а в другой все, что определяется 2-мя столбцами.

3. Первую таблицу назовем «Личные данные ученика». Первичный ключ «№ билета»

4. Вторую таблицу назовем «Родители». Первичный ключ «№ билета» и «Фамилии родителей».

5. Отношение «Родители» конечно, больше преобразованиям не подлежит.

Первичным ключом отношения «Родители» является совокупность атрибутов «Фамилии родителей» и «Номер ученического билета», т.к. только она уникально определяет экземпляры отношения. Первичный ключ отношения «Личные данные ученика» - атрибут «Номер ученического билета», т.к. он уникально определяет экземпляры отношения.

Третья нормальная форма

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

Проанализируем таблицу «Личные данные ученика». Здесь есть информация о его месте проживания, о классе, классном руководителе и специализации класса. Видно, что есть неключевые столбцы, которые зависят друг от друга. Это «Класс», «Классный руководитель» и «Специализация класса». Эти данные будут повторяться для учеников, получится слишком много повторяющейся информации. Т.е. «Специализация класса» и «Классный руководитель» зависят от неключевого атрибута «Класс». Для устранения этой зависимости выделим из отношения «Личные данные ученика» отношение «Класс». Первичным ключом созданного отношения будет атрибут «Класс».

Поэтому отношение нужно привести к третьей нормальной форме.

Выполните практическое задание 3 .Приведение отношения к третьей нормальной форме.

1. Открыть файл journal.xls. Лист Ученик.

2. Выделим из отношения «Личные данные ученика» таблицу «Класс».

3. Останется таблица «Личные данные». Однако в ней нужно оставить столбец «Класс».

4. В таблице «Класс» ключом является столбец «Класс».

ЗАМЕЧАНИЕ. Название специализации встречается многократно для разных классов. Со временем формулировка может измениться. Поэтому целесообразно сделать справочную таблицу «Справка» и сделать столбец «Код специализации».

Задание 4 .Нормализация отношения «Преподаватель».

1. Открыть файл journal.xls. Лист «Преподаватель».

2. Отношение «Преподаватель» привести к первой нормальной форме. Для этого скопировать строки, исправить данные так, чтобы в каждой строке был только один класс и предмет.

3. Выделим первичный ключ. Это столбцы «Фамилия преподавателя», «Класс» и «Предмет».

4. Анализируем и видим, что есть атрибуты, которые зависят только от фамилии преподавателя. Значит, нужно привести отношение ко второй нормальной форме.

5. Получим две таблицы. Первую назовем «Преподаватель – класс – предмет». Она уже находится в третьей нормальной форме, т.к. здесь атрибуты ключевые и все не зависят друг от друга. Вернее здесь наблюдаются связи многие-ко-многим. Отставим пока.

6. Рассмотрим вторую таблицу «Личные данные преподавателя». Первичный ключ «Фамилия». Поскольку данные преподавателя могут меняться (замуж вышла), то целесообразнее сделать столбец «Код преподавателя» и сделать этот столбец ключевым. Но тогда в отношении «Класс» нужно вместо поля «Классный руководитель» поставить «Код классного руководителя».

7. Посмотрим на столбец «Классное руководство».

8. Такая информация у нас уже есть, дублировать ее не надо. Поэтому просто вычеркнем этот столбец.

Четвертая нормальная форма

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

Вернемся в таблице «Преподаватель – класс – предмет». Здесь наблюдаются связи «многие-ко-многим». Это обозначает, что следует привести отношение к четвертой нормальной форме.

Выполните практическое задание 5 .Приведение отношения к четвертой нормальной форме.

1. Открыть файл journal.xls. Лист «Преподаватель». Отношение «Преподаватель – класс – предмет».

2. Разделим его на 2 таблицы «Преподаватель – предмет» и «Преподаватель –класс».

3. Видим, что таблица «Преподаватель – класс» осталась «многие – ко – многим». Оставим таблицу без изменений.

Аналогично нужно нормализовать отношения «Оценка» и «Кабинет».

Выполните практическое задание 6.Конечный результат.

1. Откройтефайлjournal_ready.xls.

2. Сравните эти таблицы с теми, которые получились у вас.

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

Самостоятельная работа.

Задание1. Составьте реляционную модель для таблицы «Оплата за обучение» из файла oplata.xls ,сохраните в любом удобном для вас формате (Word, Excel) с именем «Оплата за обучение».

Задание 2.(это делать на 5)

Составьте концептуальную и инфологическую модели данных по выбраннойпредметной области:

Больница (стационарное отделение)
Больница (поликлиника)
Расписание уроков в школе (предмет, учитель, время)
Библиотека (книги, читатели, библиотекари)
Дорожно-транспортные происшествия (участники, машины, обстоятельства ДТП)
Футбольный чемпионат (команды, график игр, результаты игр, футболисты)
Городская телефонная сеть (АТС, абоненты, оплата, переговоры)
Авиарейсы (самолеты, пилоты, рейсы, пассажиры)
Отдел кадров предприятия (отделы, сотрудники, должности, зарплата …)
Предприятие торговли (отделы, товары, продавцы, ….)

3.Разработайте физическую модель в изученной вами среде.

Создайте отчет и сдайте преподавателю.