Информация о сущности представляется совокупностью атрибутов. Такую совокупность атрибутов часто называют записью об объекте.
Совокупность сущностей, характеризующихся в информационной системе одним и тем же перечнем свойств, называется классом сущностей (набором объектов). Так, например, совокупность всех сущностей СТУДЕНТ составляет класс сущностей СТУДЕНТ, совокупность всех сущностей ФАКУЛЬТЕТ составляет класс сущностей ФАКУЛЬТЕТ. Класс сущностей описывается перечнем свойств сущностей, составляющих этот класс.
Экземпляром сущности будем называть конкретную сущность (сущность с конкретными значениями соответствующих свойств). Выше мы определили сущность как-то, о чем будет накапливаться информация в информационной системе. Это только одна сторона. Информация должна не просто храниться сама по себе, а использоваться для удовлетворения информационных потребностей пользователя. Для реализации подавляющего числа запросов пользователю прежде всего необходимо найти интересующий его экземпляр сущности (с целью обработки, корректировки, удаления). Поэтому важнейшим свойством сущности является однозначная идентификация ее экземпляров по одному или группе атрибутов (уникальному идентификатору). У сущности ФАКУЛЬТЕТ это, например, номер факультета, у сущности СТУДЕНТ это может быть атрибут «фамилия», если у всех студентов разные фамилии, группа атрибутов «фамилия», «имя», «отчество», или специально введенный уникальный идентификатор, например дополнительно введенный атрибут «код студента».
Наиболее распространенным способом представления концептуальной модели является так называемая ER-диаграмма. В разных источниках используются разные системы обозначений в ER-диаграммах. На практике использование различных способов записи ER-диаграмм не представляет особой сложности — беглое ознакомление с соответствующим разделом документации позволяет быстро освоить используемую систему обозначений. В данном пособии в ER-диаграмме класс сущностей будем представлять в виде четырехугольника.
В четырехугольнике записано уникальное имя класса сущности (прописными буквами) и имена атрибутов строчными буквами.
Пример класса сущностей СТУДЕНТ и конкретного экземпляра сущности показан на рис. 6.
Рисунок 6. Класс сущностей и экземпляр сущности
Для реализации иформационных потребностей пользователя недостаточно найти интересующий его экземпляр сущности. Информационные потребности тесно связаны с функциональными взаимоотношениями, существующими в организации (например, необходимо определить, на каком факультете учится конкретный студент). Для реализации таких запросов (информационных потребностей пользователя) используются существующие в предметной области взаимоотношения между сущностями. Соответствующие взаимоотношения сущностей выражаются связями (Relationships). Различают классы связей и экземпляры связей рис.
7. Классы связей — это взаимоотношения между классами сущностей, а экземпляры связи — взаимоотношения между экземплярами сущностей.
Класс связей может затрагивать несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи n = 2, 3, … Так, например, класс сущностей СТУДЕНТ связан с классом сущностей ФАКУЛЬТЕТ связью «учится на факультете». Степень этой связи равна двум. При n=2 связь называется бинарной. Заметим, что связь нужно рассматривать как двустороннюю: «студент учится на факультете» и «на факультете учатся студенты». Рассмотрим классификацию бинарных связей. В зависимости от того, сколько экземпляров сущности одного класса связаны со сколькими экземплярами сущности другого класса, различают следующие типы связей:
• Связь 1:
1. Одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и УЧЕБНЫЙ ПЛАН ПО СПЕЦИАЛЬНОСТИ ДЛЯ ФАКУЛЬТЕТА (каждому факультету соответствует свой учебный план по специальности или направлению).
• Связь 1: M. Единый экземпляр сущности одного класса связан со многими экземпля;
рами сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и СТУДЕНТ (на одном факультете учатся много студентов).
• Связь M: N. Несколько экземпляров сущности одного класса связаны с несколькими экземплярами сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ (на факультете может быть несколько специальностей и одна и таже специальность может быть на нескольких факультетах).
Рисунок 7 Пример фрагмента ER-диаграммы.
Заметим, что по этой ER-диаграмме можно указать последовательность действий, производимых при реализации запроса пользователей. Например, для реализации запроса «на каком факультете учится студент Иванов» необходимо выполнить следующие действия: найти среди экземпляров сущности СТУДЕНТ экземпляр с фамилией Иванов, перейти по связи «Студент учится на факультете» к экземпляру сущности ФАКУЛЬТЕТ, значение атрибута «Название» этого экземпляра и есть искомое название факультета. Отметим также, что иногда на ER-диаграммах две связи между сущностями изображают одной двухсторонней стрелкой или просто линией. Заметим, что на приведенной ER-диаграмме не представлены какие-либо способы реализации этих связей (на логическом и, тем более, на физическом уровнях). Соответствующие способы реализации связей зависят от возможностей модели данных конкретной СУБД и будут рассмотрены в следующей лекции (лекция 6) на второй стадии концептуального проектирования при представлении концептуальной модели средствами модели данных СУБД.
5. ПОСТРОЕНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ В ВИДЕ ER-ДИАГРАММЫ
Как уже отмечалось, концептуальная модель представляет собой обобщение представлений разных пользователей о данных. В связи с этим построение концептуальной модели, как правило, происходит в два этапа. На первом этапе производится сбор и анализ характеристик данных и строятся так называемые модели локальных представлений (локальныемодели). Чаще всего локальная модель отражает представление отдельного пользователя (отдельной функциональной задачи). Иногда такая модель может описывать и некоторую независимую область данных нескольких функциональных задач (нескольких приложений).
Здесь необходимо отметить, что моделирование представлений отдельных пользователей приводит к снижению уровня интеграции данных, а моделирование совместных представлений группы пользователей — к повышению сложности проектирования. В связи с этим при выборе области данных для локального моделирования приходится выбирать компромиссное решение между вышеуказанными вариантами.
При разработке концептуальной модели, прежде всего, следует определить сущности.
С этой целью нужно сделать следующее:
• необходимо понять, какая информация должна храниться и обрабатываться и можно ли это определить как сущность;
• присвоить этой сущности имя;
• выявить атрибуты сущности и присвоить им имя;
• определить уникальный идентификатор сущности.
Выявив сущности, необходимо определить, какие связи имеются между ними.
При определении связей (естественно, рассматриваем только те связи, которые имеют отношение к решаемым задачам обработки данных) необходимо учитывать следующее:
• то, как экземпляр одной сущности связан с экземпляром другой сущности;
• то, как должны быть установлены связи, чтобы была возможность ответа на все запросы пользователей (исходя из их информационных потребностей).
Далее необходимо присвоить связям имена и определить тип связей.
На втором этапе построенные локальные модели объединяются в обобщенную концептуальную модель.
Прежде всего, необходимо отметить, что построенная модель должна удовлетворять ряду требований:
• адекватно отражать представление пользователя о данных;
• давать возможность ответа на возможные запросы пользователя, причем делать это с минимальными затратами по количеству просматриваемых сущностей;
• представлять данные с минимальным дублированием.
Процесс построения модели, удовлетворяющей указанным требованиям, является творческим, и формализовать его, как правило, невозможно. Тем не менее можно указать некоторые способы порождения вариантов при моделировании. Выбор одного из таких вариантов на основе оценок объемов дублирования и числа просматриваемых объектов при ответах на запросы пользователей позволяет улучшить эксплуатационные характеристики проектируемой базы данных.
Вариативность моделирования обусловливается неоднозначностью выбора сущностей, атрибутов и связей. В одном варианте можно что-то взять за сущность, в другом варианте это же можно взять за атрибут (несколько атрибутов), в третьем варианте это можно определить как связь. Так, например, ранее мы определили сущеость ФАКУЛЬТЕТ с атрибутами
— «номер факультета»;
— «название факультета».
Введем сущность КАФЕДРА с атрибутами
— «номер кафедры»,
— «название кафедры».
Между этими сущностями есть связь «факультет состоит из кафедр». Возможен другой вариант, в котором вышеуказанная связь представляется через атрибуты сущности (у сущности ФАКУЛЬТЕТ введем дополнительные атрибуты, представляющие номера и названия всех кафедр этого факультета).
После того как выбран рациональный вариант локальной модели, производится редактирование введенных наименований сущностей, атрибутов и связей. Здесь выполняются следующие действия:
• устраняются расплывчатые наименования (все наименования должны однозначно пониматься каждым пользователем);
• устраняются синонимы (различные наименования одного и того же понятия);
• устраняются омонимы (одно и то же наименование разных понятий).
Эти действия, вообще говоря, носят итерационный характер, т.к. после их выполнения вновь могут возникать и расплывчатые наименования, и синонимы, и омонимы.
ЗАКЛЮЧЕНИЕ
Анализ предметной области при проектировании базы данных играет чрезвычайно важную роль в процессе разработки и проектирования прикладных баз данных. Правильно проведенный анализ предметной области позволит существенно снизить трудозатраты при проектировании базы данных, а так же построить эффективную логическую и физическую модели базы данных.
Для создания базы данных и работы с ней используется система управления базами данных. Каждая конкретная СУБД поддерживает определенный вид данных (форматов записей и отношений), называемый моделью данных СУБД.
Проектирование данных (базы данных) представляет собой процесс последовательного отображения исследуемых явлений реального мира в виде данных в памяти ЭВМ Наиболее распространенным способом представления концептуальной модели является так называемая ER-диаграмма. По ER-диаграмме можно указать последовательность действий, производимых при реализации запроса пользователей.
1. Дейт К. Дж.
Введение
в системы баз данных — 8-е изд. — М.: «Вильямс», 2006.
2. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — 3-е изд. — М.: «Вильямс», 2003.
3. Кузнецов С. Д. Основы баз данных. — 1-е изд. — М.: «Интернет-университет информационных технологий — ИНТУИТ.ру», 2005.
4. Скотт В. Эмблер, Прамодкумар Дж. Садаладж. Рефакторинг баз данных: эволюционное проектирование — М.: «Вильямс», 2007.
5. Кириллов В. В. Основы проектирования реляционных баз данных. Учебное пособие. — СПб.: ИТМО, 1994.
6. Бутко В. Р., Дерябкин В. П. CASE — технологии моделирования и проектирования АИСУчебн. пособие. — Самара: Изд-во Самарск.
Гос. Экон. академ., 2001.-105 с.
7. Довгялло И. И., Трифонова Л. Т., Юдина С. М. Система управления базами данных Visual FoxPro:. Учебн. пособие. — Самара: Изд-во Самарск. Гос. Экон.
академ., 2000.-161 с.
8. Абросимов А. Г., Бородинова М. А. Теория экономических информационных систем. — Самара; Изд-во Самарск. Гос. Экон.
академ., 2001. 170 с.
9. A.M. Вендров. Проектирование программного обеспечения. /Учебник — М.: Финансы и статистика, 2000.
10. Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. Проектирование экономических информационных систем: Учебник. — М.: Финансы и статистика, 2002.
11. Маклаков С. В. Bpwin и Erwin. CASEсредства разработки информационных систем. — М.: «ДИАЛОГМИФИ «, 1999,256с.
12. Буч Г. Объектно — ориентированное проектирование с примерами применения/ Пер. с англ. — М.: Конкорд, 1992.
13. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя / Пер. с англ. — М.:ДМК, 2000. — 432с
14. Базы данных: модели, разработка, реализация /Т.С. Карпова. — СПб: Питер, 2002.-304с.
15. Журнал «Компью
Терра" № 37−38 1994.
