Лекция № 11. Проектирование схем баз данных
Лекция № 11. Проектирование схем баз данных
Наиболее распространенным средством абстрактного представления схем баз данных при проектировании на логическом уровне является так называемая модель «сущность – связь». Ее еще иногда называют ER-модель, где ER – аббревиатура английского словосочетания Entity – Relationship, что буквально и переводится как «сущность – связь».
Элементами таких моделей являются классы сущностей, их атрибуты и связи.
Дадим объяснения и определения каждого из этих элементов.
Класс сущностей – это как бы лишенный методов класс объектов в смысле объектно-ориентированного программирования. При переходе к физическому уровню классы сущностей преобразовываются в базовые отношения реляционных баз данных для конкретных систем управления базами данных. У них, как и у собственно базовых отношений, существуют собственные атрибуты.
Дадим более точное и строгое определение только что приведенных объектов.
Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Графически обычно класс изображается в виде прямоугольника. У каждого класса должно быть имя (текстовая строка), уникально отличающее его от всех других классов.
Атрибутом класса называется именованное свойство класса, описывающее множество значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов (в частности, не иметь ни одного атрибута). Свойство, выражаемое атрибутом, является свойством моделируемой сущности, общим для всех объектов данного класса. Так что атрибут является абстракцией состояния объекта. Любой атрибут любого объекта класса должен иметь некоторое значение.
Так называемые связи реализуются с помощью объявления внешних ключей (подобные явления нам уже встречались раньше), т. е. в отношении объявляются внешние ключи, ссылающиеся на первичные или кандидатные ключи каких-то других отношений. И посредством этого и происходит «связывание» нескольких различных самостоятельных базовых отношений в единую систему, называемую базой данных.
Далее диаграмма, составляющая графическую основу модели «сущность – связь», изображается при помощи унифицированного языка моделирования UML.
Языку объектно-ориентированного моделирования UML (или Unified Modeling Language) посвящено великое множество книг, многие из которых переведены на русский язык (а некоторые и написаны российскими авторами).
Вообще, UML позволяет моделировать разные виды систем: чисто программные, чисто аппаратные, программно-аппаратные, смешанные, явно включающие деятельность людей и т. д.
Но, помимо прочего, как мы уже упоминали, язык UML активно применяется для проектирования реляционных баз данных. Для этого используется небольшая часть языка (диаграммы классов), да и то не в полном объеме. С точки зрения проектирования реляционных баз данных, модельные возможности не слишком отличаются от возможностей ER-диаграмм.
Мы также хотели показать, что в контексте проектирования реляционных баз данных структурные методы проектирования, основанные на использовании ER-диаграмм, и объектно-ориентированные методы, основанные на использовании языка UML, различаются главным образом, лишь терминологией. ER-модель концептуально проще UML, в ней меньше понятий, терминов, вариантов применения. И это понятно, поскольку разные варианты ER-моделей разрабатывались именно для поддержки проектирования реляционных баз данных, и ER-модели почти не содержат возможностей, выходящих за пределы реальных потребностей проектировщика реляционной базы данных.
Язык UML принадлежит объектному миру. Этот мир гораздо сложнее (если угодно, непонятнее, запутаннее) реляционного мира. Поскольку UML может использоваться для унифицированного объектно-ориентированного моделирования всего чего угодно, в этом языке содержится масса различных понятий, терминов и вариантов использования, избыточных с точки зрения проектирования реляционных баз данных. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных баз данных, то мы получим в точности ER-диаграммы с другой нотацией и терминологией.
Любопытно, что при формировании имен классов в UML допускается использование произвольной комбинации букв, цифр и даже знаков препинания. Однако на практике рекомендуется использовать в качестве имен классов короткие и осмысленные прилагательные и существительные, каждое из которых начинается с заглавной буквы.
(Подробнее понятие диаграммы мы рассмотрим в следующем параграфе нашей лекции.)
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
ЛЕКЦИЯ № 5. Строковый тип данных
ЛЕКЦИЯ № 5. Строковый тип данных 1. Строковый тип в Pascal Последовательность символов определенной длины называется строкой. Переменные строкового типа определяются путем указания имени переменной, зарезервированного слова string, и возможно, но не обязательно указания
ЛЕКЦИЯ № 9. Древовидные структуры данных
ЛЕКЦИЯ № 9. Древовидные структуры данных 1. Древовидные структуры данных Древовидной структурой данных называется конечное множество элементов-узлов, между которыми существуют отношения – связь исходного и порожденного.Если использовать рекурсивное определение,
ЛЕКЦИЯ № 11. Объектный тип данных
ЛЕКЦИЯ № 11. Объектный тип данных 1. Объектный тип в Pascal. Понятие объекта, его описание и использование Исторически первым подходом в программировании являлось процедурное программирование, иначе называемое программированием снизу вверх. Вначале создавались общие
Проектирование структуры данных
Проектирование структуры данных Как и построение здания, построение базы данных начинается с проектирования. Чтобы понять, какая структура базы будет для вас наиболее удобной и полезной, следуйте нижеприведенным этапам проектирования.1. Для начала необходимо выяснить,
Проектирование базы данных
Проектирование базы данных Для создания базы данных в первую очередь нужно определить, какого рода информацию ей предстоит отслеживать. Затем можно приступать к проектированию, создавая таблицы, состоящие из полей, которые определяют типы хранимых данных. После
1.3. Проектирование базы данных
1.3. Проектирование базы данных Построение базы данных (как и любой информационной системы, любого программного продукта) начинается с проектирования. В процессе его мы определяем задачи, для решения которых предназначена база данных, и создаем представление о данных и
Лекция № 3. Реляционные объекты данных
Лекция № 3. Реляционные объекты данных 1. Требования к табличной форме представления отношений 1. Самое первое требование, предъявляемое к табличной форме представления отношений, – это конечность. Работать с бесконечными таблицами, отношениями или любыми другими
1. Смысл нормализации схем баз данных
1. Смысл нормализации схем баз данных Понятие, которое мы будем рассматривать в данном разделе, связано с понятием функциональных зависимостей, т. е. смысл нормализации схем баз данных неразрывно связан с понятием ограничений, накладываемых системой функциональных
Проектирование базы данных
Проектирование базы данных Хотя реляционные базы данных являются очень гибкими, существует только один способ обеспечения целостности данных и удовлетворительной производительности базы данных - основательное проектирование базы данных. Не существует никакой
Проектирование логической структуры базы данных
Проектирование логической структуры базы данных Итак, мы определили состав дескрипторов, то есть ключевых полей для поиска, по которым чаще всего (по нашему прогнозу) будут формироваться запросы к базе данных. Теперь начнем разработку логической структуры БД. Под
Лекция 6. Абстрактные типы данных (АТД)
Лекция 6. Абстрактные типы данных (АТД) Чтобы объекты играли лидирующую роль в архитектуре ПО, нужно их адекватно описывать. В этой лекции показывается, как это делать. Если вам не терпится окунуться в глубины объектной технологии и подробно изучить множественное
Лекция 11. Проектирование по контракту: построение надежного ПО
Лекция 11. Проектирование по контракту: построение надежного ПО Вооруженные базисными концепциями класса, объекта, параметризации вы можете теперь создавать программные модули, реализующие возможно параметризованные типы структур данных. Мои поздравления! Сделан
4.5. ПРОЕКТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ ОПЕРАТИВНЫХ СТРУКТУР ДАННЫХ
4.5. ПРОЕКТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ ОПЕРАТИВНЫХ СТРУКТУР ДАННЫХ Ряд рассмотренных структур данных можно реализовать с использованием статических структур данных, динамических переменных и динамических структур данных. Многовариантность реализации структур
Лекция 20. Проектирование и внедрение PKI
Лекция 20. Проектирование и внедрение PKI Подробно рассматривается процесс проектирования PKI, приводится краткая характеристика основных правовых документов PKI, описываются соглашения между участниками PKI, даются рекомендации по выбору основных средств и оборудования,