В. И. Швецов Базы данных
 Скачать 8.45 Mb.
|
5.2.1 Основные этапы построенияКак уже отмечалось, концептуальная модель представляет собой обобщение представлений разных пользователей о данных. В связи с этим построение концептуальной модели, как правило, происходит в два этапа. На первом этапе производится сбор и анализ характеристик данных и строятся так называемые модели локальных представлений (локальные модели). Чаще всего локальная модель отражает представление отдельного пользователя (отдельной функциональной задачи). Иногда такая модель может описывать и некоторую независимую область данных нескольких функциональных задач (нескольких приложений). Здесь необходимо отметить, что моделирование представлений отдельных пользователей приводит к снижению уровня интеграции данных, а моделирование совместных представлений группы пользователей – к повышению сложности проектирования. В связи с этим при выборе области данных для локального моделирования приходится выбирать компромиссное решение между вышеуказанными вариантами. 4.3. Выявление и моделирование сущностей и связей При разработке концептуальной модели, прежде всего, следует определить сущности. С этой целью нужно сделать следующее:
Выявив сущности, необходимо определить, какие связи имеются между ними. При определении связей (естественно, рассматриваем только те связи, которые имеют отношение к решаемым задачам обработки данных) необходимо учитывать следующее:
Далее необходимо присвоить связям имена и определить тип связей. На втором этапе построенные локальные модели объединяются в обобщенную концептуальную модель. 5.2.2. Моделирование локальных представленийПрежде всего, необходимо отметить, что построенная модель должна удовлетворять ряду требований:
Процесс построения модели, удовлетворяющей указанным требованиям, является творческим, и формализовать его, как правило, невозможно. Тем не менее можно указать некоторые способы порождения вариантов при моделировании. Выбор одного из таких вариантов на основе оценок объемов дублирования и числа просматриваемых объектов при ответах на запросы пользователей позволяет улучшить эксплуатационные характеристики проектируемой базы данных. Вариативность моделирования обусловливается неоднозначностью выбора сущностей, атрибутов и связей. В одном варианте можно что-то взять за сущность, в другом варианте это же можно взять за атрибут (несколько атрибутов), в третьем варианте это можно определить как связь. Так, например, ранее мы определили сущеость ФАКУЛЬТЕТ с атрибутами «номер факультета», «название факультета». Введем сущность КАФЕДРА с атрибутами «номер кафедры», «название кафедры». Между этими сущностями есть связь «факультет состоит из кафедр». Возможен другой вариант, в котором вышеуказанная связь представляется через атрибуты сущности (у сущности ФАКУЛЬТЕТ введем дополнительные атрибуты, представляющие номера и названия вскх кафедр этого факультета). После того как выбран рациональный вариант локальной модели, производится редактирование введенных наименований сущностей, атрибутов и связей. Здесь выполняются следующие действия:
Эти действия, вообще говоря, носят итерационный характер, т.к. после их выполнения вновь могут возникать и расплывчатые наименования, и синонимы, и омонимы. 5.2.3. Объединение локальных моделейНа этом этапе ранее построенные модели локальных представлений отдельных пользователей (или групп пользователей) объединяются в единую концептуальную модель. Объединение локальных моделей производится следующими путями:
Рассмотрим каждый из этих путей. Слияние идентичных элементов Два или более элементов модели идентичны, если они имеют одинаковое смысловое значение. Объединение моделей с идентичными элементами осуществляется путем «слияния» этих элементов в один. Два набора сущностей СПЕЦИАЛЬНОСТЬ в модели 1 и 2 имеют одинаковое смысловое значение (рис. 5.3.), и могут быть заменены одним набором сущностей (рис. 5.4.).  Рис. 5.3.. Модели с идентичным элементом  Рис.5.4.. Объединенная модель Установление связей между наборами сущностей разных моделей При рассмотрении наборов сущностей объединяемых моделей необходимо выявление связей между ними, т.к. именно эти связи и определяют в конечном итоге интегрированную базу данных. Введение агрегированных элементов При объединении моделей связь между элементами разных моделей может рассматриваться как новый элемент. Рассмотрим в качестве примера моделирование информационного представления сдачи студентом экзаменов. Можно выделить ряд локальных представлений (рис. 5.5.).  Рис.5.5. Локальные представления Объединяя локальные представления, устанавливаем новые связи (рис. 5.6.).  Рис.5.6.. Объединение локальных представлений Как уже отмечалось, одним из показателей «зрелости» модели является возможность ответа на запросы пользователей, и установление связей преследует именно эту цель. Нетрудно видеть, что какие бы связи в рассматриваемой модели ни вводились, невозможно ответить на запрос «какую оценку получил студент А по дисциплине В». В таком случае необходимо использовать принцип агрегации – необходимую связь между элементами модели ввести как некоторый новый элемент. В данном примере можно определить этот новый агрегированный элемент как ЭКЗАМЕН СТУДЕНТА (рис. 5.7.).  Рис. 5.7. Агрегированный элемент. Далее процесс объединения локальных моделей продолжается обычным образом. Обобщение подобных типов сущностей Рассмотрим локальные модели разных факультетов, например – модель факультета вычислительной математики и кибернетики (ВМК), модель экономического факультета и так далее. В локальную модель факультета ВМК входят сущности СПЕЦИАЛЬНОСТИ ФАКУЛЬТЕТА ВМК и СТУДЕНТЫ ФАКУЛЬТЕТА ВМК, в локальную модель экономического факультета входят, соответственно, сущности СПЕЦИАЛЬНОСТИ ЭКОНОМИЧЕСКОГО ФАКУЛЬТЕТА и СТУДЕНТЫ ЭКОНОМИЧЕСКОГО ФАКУЛЬТЕТА (рис. 5.8.).  Рис. 5.8. Модели с подобным элементом Два набора сущностей CПЕЦИАЛЬНОСТИ ФАКУЛЬТЕТА ВМК и СПЕЦИАЛЬНОСТИ ЭКОНОМИЧЕСКОГО ФАКУЛЬТЕТА в моделях 1 и 2 имеют одинаковое смысловое значение и могут быть заменены одним набором сущностей с добавлением нового атрибута – название факультета (рис. 5.9.).  Рис. 5.9. Пример обобщенной сущности Отметим, что в данном случае подобным образом можно слить и все остальные сущности локальных моделей факультетов, так как сущности СТУДЕНТЫ ЭКОНОМИЧЕСКОГО ФАКУЛЬТЕТА и СТУДЕНТЫ ВМК также имеют одинаковое смысловое значение и их также можно объединить. Однако в общем случае каждая локальная модель может содержать сущности и связи, которых нет в других локальных моделях. Рассмотрим другой пример. Предположим, что мы храним данные о студентах (фамилия, имя, отчество, курс, группа) и о преподавателях (фамилия, имя, отчество, кафедра, должность). Соответственно, в предметной области выделяем две сущности – СТУДЕНТ и ПРЕПОДАВАТЕЛЬ. Эти разные сущности можно в некоторых случаях трактовать как подобные. Для обобщения соответствующих сущностей необходимо, прежде всего, обобщить их атрибуты. Заметим, что атрибуты «ФИОФамилия, Имя, Отчество» у обеих сущностей совпадают, атрибуты «Кафедра» и «Курс», «Группа» показывают место работы (учебы) и их можно заменить обобщенным атрибутом «Место работы (учебы)». Атрибут «Должность» можно использовать и у сущности СТУДЕНТ, если в качестве значения соответствующего атрибута использовать значение «студент». Тогда две сущности ПРЕПОДАВАТЕЛЬ и СТУДЕНТ можно трактовать как подобные и заменить их на обобщенную сущность. Дадим этой обобщенной сущности название КАДРОВАЯ ЕДИНИЦА (рис. 5.10.).  Рис. 5.10. Пример обобщенной сущности У студента атрибут «Место работы (учебы)» будет принимать значение соответствующее атрибутам «Курс. Группа», у преподавателя – название кафедры. Обобщенная модель представлена на рис. 5.11.  Рис. 5.11. Обобщенная модель В этом случае почти в два раза упрощается структура концептуальной модели, и соответственно, структура базы данных. Для работы с данными о преподавателях и студентах достаточно одного набора программ. Таким образом, обобщение подобных типов объектов может существенно сократить последующие затраты на программирование. В процессе объединения локальных представлений, как и при локальном моделировании, производится редактирование наименований (т.к. здесь появляются новые наименования). Процесс объединения также носит итерационный характер и продолжается до тех пор, пока не будут интегрированы все представления, согласованы и устранены все противоречия, отредактированы все наименования. Полученное в результате объединения локальных представлений обобщенное представление и является концептуальной моделью. 5.3. Ограничения целостности Под целостностью базы данных понимается то, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область (правильная) информация. Огромный объем данных, вводимых в базу данных (– причем разные данные могут вводиться разными пользователями), – обусловливает большое число ошибок ввода (занесения). Заметим, что при традиционной «бумажной» обработке информации также достаточно часто встречаются данные, записанные неверно. Но человек, работая с определенными данными, неявно использует для контроля имеющиеся у него представления об этих данных. Например, сотрудник отдела кадров, увидев в карточке работника год рождения 1693, сразу заметит эту ошибку и предположит, что просто переставлены две цифры и реальный год рождения 1963. То есть в представлениях сотрудника заключены некоторые логические ограничения на данные. Очевидно, что для контроля правильности вводимых данных при работе с базой данных целесообразно сформировать и использовать ограничения. Соответствующие ограничения обычно разделяют на 3 группы: внешние, специально конструироваемые и внутренние. К предметной области относятся первые две группы, которые мы кратко охарактеризуем в этом подразделе. Внутренние ограничения относятся уже к модели данных и будут рассматриваться в разделе, посвященном модели данныхсоответствующем разделе. Внешние ограничения. Эти ограничения связаны с адекватностью отражения предметной области. Например, сотрудник организации не может быть моложе 17 и старше 90 лет. Соответствующее ограничение на год рождения (GR) можно записать следующим образом: Текущий год – 17 > GR > Текущий год – 90. Одним из способов задания таких ограничений является перечисление конечного множества допустимых значений какого-либо атрибута (так называемый «перечислимый» тип данных). Например, должность преподавателя в вузе может принимать одно из следующих значений: профессор, доцент, старший преподаватель, преподаватель, ассистент. Вводимое значение должности для конкретного экземпляра, не совпадающее с одним из перечисленных значений, является ошибкой. Ограничения, описанные с помощью специальных конструкций. Например, в базу данных вуза вводятся данные о числе студентов и преподавателей. По нормативным документам задано конкретное значение отношения числа студентов к числу преподавателей. Проверку этого отношения можно использовать для контроля достоверности данных. Такие конструкции строятся исходя из специфики данных рассматриваемой предметной области. Можно, например, построить много конструкций следующего вида: сумма значений по заданному атрибуту по всем экземплярам сущностей должна совпадать со значением определенного атрибута в экземпляре другой сущности. Таким образом, на стадии ER-моделирования для повышения достоверности данных необходимо сформулировать соответствующие ограничения на данные. В идеальном случае каждое значение атрибута должно каким-то образом контролироваться. Использование этих ограничений позволяет существенно повысить достоверность данных в базе данных. Краткие итоги. Рассмотрен процесс моделирования предметной области. Определены используемые при этом основные понятия (сущность, атрибут, идентификатор, связь, типы связей, ER-диаграмма). Рассмотрены основные этапы моделирования сущностей и связей (моделирование локальных представлений, объединение локальных моделей с ипользованием понятий идентичность, агрегация., обобщение). Дано понятие ограничений целостности, имеющих непосредственное отношение к предметной области (внешние ограничения; ограничения, описанные с помощью специальных конструкций). Более подробно с материалом этой лекции можно познакомиться в [1-10]. Контрольные тесты Задача 1. С помощью какого основного понятия описывается то, о чем будет накапливаться информация в информационной системе? Вариант 1. Как называется основное понятие, с помощью которого описывается то, о чем будет накапливаться информация в информационной системе? атрибут + ð+ объект + ð+ сущность идентификатор Вариант 2. Чем отличаются понятия сущность и объект в базах данных? + ð+ одно и тоже сущность используется для описания объекта это разные понятия объект используется для описания сущности Вариант 3. Что из следующих примеров можно определить как сущность? название экзамена фамилию студента + ð+ факультет + ð+ оценка + ð+ предмет Задача 2. Какие понятия используются для описания сущности? Вариант 1. Как называется понятие, используемое для описания сущности? + ð+ свойство + ð+ атрибут объект экземпляр Вариант 2. Чем отличаются понятия свойство и атрибут? одно и то же + ð+ атрибут это свойство, принимающее конкретные значения свойство используется для описания атрибута атрибут описывает конкретное свойство Вариант 3. Как описывается сущность? + ð+ совокупностью атрибутов набором экземпляров совокупностью объектов + ð+ записью об объекте Задача 3. В чем разница между классом сущностей и экземплярами сущности? Вариант 1. Что такое класс сущностей? набор экземпляров сущностей + ð+ совокупность сущностей с одинаковыми свойствами совокупность атрибутов совокупность сущностей с одинаковыми значениями атрибутов Вариант 2. Какое понятие используется для представления конкретной сущности? + ð+ экземпляр сущности атрибут сущности идентификатор сущности класс сущности Вариант 3. Что такое экземпляр сущности? + ð+ сущность с конкретными значениями свойств совокупность атрибутов сущность с конкретным названием сущность с определенным именем идентификатора Задача 4. Как определяется понятие связи? Вариант 1. Чем определяется существование связи между сущностями ð+ +функциональными взаимоотношениями между сущностями + ð+ информационными связями между сущностями информационными потребностями пользователя + ð+ свойствами сущностей Вариант 2. Какие бывают типы связей? + ð+ один к одному + ð+ один к многим + ð+ многие к многим + ð+ многие к одному Вариант 3. Между какими элементами рассматриваются связи? + ð+ между сущностями + ð+ между экземплярами сущностей между атрибутами + ð+ между классами сущностей Задача 5. В чем разница между классами связей и экземплярами связей? Вариант 1. Что такое класс связей? + ð+ взаимоотношения (набор связей) между классами сущностей набор связей типа «многие к многим» набор связей типа «один к многим» набор связей между экземплярами сущностей Вариант 2. Что такое экземпляры связей? + ð+ взаимоотношения между экземплярами сущностей взаимоотношения (набор связей) между классами сущностей взаимоотношения между атрибутами взаимоотношения между сущностями Вариант 3. Что такое степень связи? + ð+ число классов сущности, участвующих в связи максимальное количество экземпляров сущностей на каждой стороне связи число экземпляров сущности, участвующих в связи количество связей между экземплярами сущностей Задача 6. Что такое ER-диаграмма ? Вариант 1. Для чего используется ER-диаграмма? + ð+ графическое представление концептуальной модели ð+ +графическое представление сущностей и связей между ними ð+ +графическое представление обобщенного представления пользователей о данных графическое представление всех сущностей графическое представление связей Вариант 2. Что представляется на ER-диаграмме ð+ +сущности ð+ +связи ð+ +типы связей + ð+ атрибуты экземпляры сущностей Вариант 3. Как на ER-диаграмме представляются способы реализации связей? + ð+ не представляются в виде адресных ссылок представляются на логическом уровне представляются на физическом уровне Задача 7. Основные этапы построения концептуальной модели. Вариант 1. Какой порядок действий при построении концептуальной модели? + ð+ определение сущностей, определение атрибутов, установление связей определение атрибутов, определение сущностей, , установление связей выбор связей, определение сущностей, определение атрибутов выбор экземпляров сущностей, установление связей между экземплярами Вариант 2. Что такое локальное моделирование? моделирование одной сущности моделирование представления одного пользователя + ð+ моделирование представлений группы пользователей, использующих общие данные моделирование представлений группы пользователей, использующих разные данные Вариант 3. Как редактируются локальные модели? + ð+ устраняются расплывчатые наименования сущностей и атрибутов ð+ +устраняются синонимы в наименованиях сущностей и атрибутов ð+ +устраняются омонимы в наименованиях сущностей и атрибутов + ð+ изменяются наименования сущностей и атрибутов Задача 8. Как локальные модели объединяются в обобщенную концептуальную модель? Вариант 1. Какие приемы используются при объединении локальных моделей? отбрасываются некоторые идентичные элементы ð+ +сливаются идентичные элементы + ð+ локальные модели объединяются по новым связям локальные модели объединяются по имеющимся в них связям ð+ +подобные типы сущностей обобщаются подобные типы сущностей исключаются + ð+ вводятся новые сущности Вариант 2. Что такое «введение агрегированного элемента» ? объединение нескольких сущностей разбиение сущности на несколько сущностей ð+ +определение новой сущности + ð+ рассмотрение связи как новой сущности Вариант 3. Что такое «обобщение подобных типов сущностей» ? подобные типы сущностей сливаются подобные типы сущностей удаляются ð+ +определяется новая сущность + ð+ подобные типы сущностей заменяются на другую сущность Задача 9. Что такое ограничения целостности? Вариант 1. Зачем нужны ограничения целостности? + ð+ для обеспечения правильного ввода данных в базу данных + ð+ для обеспечения достоверной информации в базе данных для проверки правильности работы прикладных программ для уменьшения ошибок при поиске данных Вариант 2. Какие существуют типы ограничений целостности ? + ð+ внешние ð+ +внутренние специально конструируемые в прикладных программах + ð+ специально конструируемые в программах СУБД Вариант 3. Откуда берутся внешние и специально конструируемые ограничения? + ð+ определяются предметной областью определяются СУБД определяются прикладными программами ð+ +определяются пользователем определяются программистом Литература
Лекция 6. Вторая стадия концептуального проектирования ( Модели данных СУБД. представление концептуальной модели средствами модели данных СУБД) Лекция посвящена второй стадии концептуального проектирования – представлениию концептуальной модели в терминах модели данных определенной СУБД. Здесь дается общее понятие модели данных СУБД, рассматриваются типовые классические модели данных, рассматриваются принципы автоматизированного проектирования баз данных. Ключевые словатермины: модель данных, сетевая модель, иерархическая модель, реляционная модель, многомерная модель, представление концептуальной модели, логическое проектирвание, автоматизированное проектирование баз данных. Цель лекции: дать общее представление о модели данных СУБД как средства для представления концептуальной модели при создании базы данных, рассмотреть типовые модели данных (сетевая модель, иерархическая модель, реляционная модель, многомерная модель), показать как представляяется концептуальная модель в разных СУБД, рассмотреть основные принципы работы средств автоматизированного проектирования баз данных. 6.1. Представление концептуальной модели средствами модели данных СУБД Общие представления о моделях данных СУБД В соответствии с основными этапами проектирования базы данных после построения концептуальной модели выбирается система управления базой данных, с помощью которой будет организована база данных и работа с ней. Каждая СУБД поддерживает определенные виды и типы данных, а также средства представления связей между данными, составляющими модель данных СУБД. Вторая стадия проектирования базы данных состоит в представлении построенной на предидущей стадии концептуальной модели средствами модели данных СУБД или в отображении концептуальной модели в модель данных СУБД. Этот этап часто называют логическим проектированием базы данных. Полученная при этом модель часто также называется концептуальной моделью или схемой (но специфицированной к понятиям модели данных СУБД). В некоторых источниках полученную модель называют логической структурой данных или моделью данных базы данных. Можно по-разному характеризовать понятие модели данных СУБД. С одной стороны, модель данных СУБД – это способ структурирования данных, которые рассматриваются как некоторая абстракция в отрыве от предметной области. С другой стороны, модель данных СУБД– это инструмент представления концептуальной модели предметной области и динамики ее изменения в виде базы данных. Учитывая обе вышеуказанные стороны, определим основные структуры моделей данных СУБД, используемые для представления концептуальной модели предметной области (сущностей, атрибутов, связей). Элемент данных (поле) – наименьшая поименованная единица данных. Используется для представления значения атрибута. С элементом данных неразрывно связано понятие «тип данных», который может принимать соответствующее поле. В разных СУБД могут использоваться разные типы данных, наиболее распространенными из которых (используемые во многих СУБД) являются следующие: числовой (numeric), символьный (char), дата (date) и т.д. Запись – поименованная совокупность полей. Используется для представления совокупности атрибутов сущности (записи о сущности). Экземпляр записи – запись с конкретными значениями полей. Первичный ключ – минимальный набор полей записи, однозначно идентифицирующих экземпляр записи файла. Файл – поименованная совокупность экземпляров записей одного типа. Используется для представления однородного набора сущностей. Набор файлов – поименованная совокупность файлов, обрабатываемых в системе. Используется для представления нескольких наборов сущностей. Введем понятие «группа», обобщающее понятия «файл» и «запись». Группа – это поименованная совокупность элементов данных или элементов данных и других групп. Важнейшим понятием концептуальной модели является понятие связи между сущностями (наборами сущностей). В моделях данных СУБД соответствующее понятие отражается понятием «групповое отношение». Групповое отношение – поименованное бинарное отношение, заданное на двух множествах экземпляров рассматриваемых групп. По характеру бинарных связей различают групповые отношения вида 1:1, 1:M, M:1, M:N. Пары чисел называют коэффициентами группового отношения. В групповом отношении один член группы назначается владельцем отношения, другой – членом. База данных – поименованная совокупность экземпляров групп и групповых отношений. Для представления группового отношения используется две формы: а) Графовая. Группы изображаются вершинами графа, связи между группами – дугами, направленными от группы-владельца к группе-члену с указанием имени отношения и коэффициента. По типу графов различают:
б) Табличная. Связь между группами изображается таблицей, столбцы которой представляют ключи соответствующих групп. Для формального описания таблицы используется математическое (теоретико-множественное) понятие отношения. Соответствующая модель данных называется реляционной моделью. Модель данных СУБД описывается следующим образом:
В качестве основных элементарных операций обычно рассматриваются следующие: поиск записи с заданным значением ключа, чтение нужной записи, добавление записи, корректировка, удаление. В моделях данных СУБД также предусматриваются специальные операции для установления групповых отношений. Обобщенные операции или процедуры – последовательность операций, реализующая определенный алгоритм обработки данных. Процедуры могут инициироваться СУБД автоматически, а также могут запускаться пользователем. Примерами процедур являются процедуры копирования БД, восстановления БД, процедуры, вычисляющие значения определенных атрибутов в БД по значениям других атрибутов, и т.п. Средства контроля используются для реализации ограничений целостности концептуальной модели. Простейшие средства контроля – ограничения – используются для реализации как внешних ограничений концептуальной модели, так и внутренних ограничений модели данных. В качестве последних ограничений, в частности, реализованы ограничения на ввод данных несоответствующего типа, несоответствующей характеристики (по числу битов, по числу полей, по количеству записей и т.п.). Более сложные средства контроля (правила) позволяют вызывать выполнение определенной последовательности операций (сколь угодно сложной) при изменении или добавлении данных в БД и тем самым реализовывать ограничения целостности, описанные с помощью специальных конструкций. Построение модели данных базы данных (отображение концептуальной модели в модель данных СУБД) После первой стадии концептуального проектирования у нас сформировано обобщенное представление пользователей о данных, как правило, представленное в виде ER-диаграммы .На следующей стадии (после того, как выбрана определенная СУБД с конкретной моделью данных) необходимо записать концептуальную схему в терминах и понятиях выбранной СУБД. На этой стадии каждая сущность концептуальной модели описывается как запись, состоящая из полей. Каждый атрибут описывается как поле с типом и характеристиками, возможными в выбранной СУБД. Описываются связи концептуальной модели в понятиях, соответствующих выбранной СУБД, определяется порядок реализации запрсов пользователей к базе данных с помощью типовых операций СУБД и т. д. Результатом зтой стадии проектирования будет концептуальная модель, специфицированная к конкретной СУБД. 6.2 Типовые модели данных СУБД и представление концептуальной модели |