Основные  данные о работе

Оглавление

Введение

     Принято считать, что реляционный подход к организации баз данных был заложен в конце 1960-х гг. Эдгаром Коддом. В последние десятилетия этот подход является наиболее распространенным.

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

     Компьютерный  мир далеко не сразу признал реляционные системы. В 70-е года прошлого века, когда уже были получены почти все основные теоретические результаты и даже существовали первые прототипы реляционных СУБД, многие авторитетные специалисты отрицали возможность добиться эффективной реализации таких систем. Однако преимущества реляционного подхода и развитие методов и алгоритмов организации и управления реляционными базами данных привели к тому, что к концу 80-х годов реляционные системы заняли на мировом рынке СУБД доминирующее положение.

     На  использовании разновидностей ER-модели основано большинство современных  подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г.

     Основными понятиями ER-модели являются сущность, связь и атрибут.

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

     Каждый  экземпляр сущности должен быть отличим  от любого другого экземпляра той же сущности.

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

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

     Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

     Целью данной работы является детальное рассмотрение понятия "ER-модель".

     Задачами  работы являются рассмотрение концепции ER-модели, графическое представление, связь ER-модели и реляционной базы данных.

    1. Проектирование базы данных

    1.1. Семантические модели данных 

    Широкое распространение реляционных СУБД и их использование в самых  разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе кратко рассмотренного механизма нормализации часто представляет собой очень сложный и неудобный для проектировщика процесс.

    При этом проявляется ограниченность реляционной  модели данных в следующих аспектах:

• Модель не предоставляет достаточных средств для представления смысла данных. Семантика реальной предметной области должна независимым от модели способом представляться в голове проектировщика. В частности, это относится к упоминавшейся нами проблеме представления ограничений целостности.
• Для многих приложений трудно моделировать предметную область на основе плоских таблиц. В ряде случаев на самой начальной стадии проектирования проектировщику приходится производить насилие над собой, чтобы описать предметную область в виде одной (возможно, даже ненормализованной) таблицы.
• Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.
• Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области ("сущностей") и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связей.

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

     Метод сущность-связь называют также методом "ER-диаграмм": во-первых, ER –аббревиатура от слов Essence (сущность) и Relation (связь), во-вторых, метод основан на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.

    Наиболее  часто на практике семантическое  моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную концептуальная схема преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.

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

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

1.2. Основные этапы проектирования баз данных

     Концептуальное (инфологическое) проектирование –  построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм. Такая модель строится без ориентации на какую-либо конкретную СУБД.

     Основные  элементы данной модели:

1. Описание объектов предметной области и связей между ними.
2. Описание информационных потребностей пользователей (описание основных запросов к БД).
3. Описание документооборота. Описание документов, используемых как исходные данные для БД и документов, составляемых на основе БД.
4. Описание алгоритмических зависимостей между данными.
5. Описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.

     Логическое (даталогическое) проектирование –  отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.

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

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

1. основные объекты предметной области (объекты, о которых должна храниться информация в БД);
2. атрибуты объектов;
3. связи между объектами;
4. основные запросы к БД.

2. ER-диаграммы

2.1 Концепции ER-модели

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

       Во многих случаях информационная  модель очень сложна и содержит множество объектов. Основные понятия ER-диаграмм

     Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.

     Каждая  сущность должна иметь наименование, выраженное существительным в единственном числе.

     Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная".

     Каждая  сущность в модели изображается в  виде прямоугольника с наименованием (Рис.1):

     Рис. 1 Сущность «Сотрудник»

     Определение 2. Экземпляр сущности - это конкретный представитель данной сущности.

     Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".

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

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

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

     Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.

     Атрибуты  изображаются в пределах прямоугольника, определяющего сущность (Рис. 2):

     Рис. 2 Атрибуты сущности «Сотрудник»

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

     Сущность  может иметь несколько различных  ключей.

     Ключевые  атрибуты изображаются на диаграмме  подчеркиванием (Рис.3):

     Рис. 3 Изображение ключевого атрибута

     Определение 5. Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.

     Связи позволяют по одной сущности находить другие сущности, связанные с нею.

     Например, связи между сущностями могут  выражаться следующими фразами - "СОТРУДНИК  может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".

     Графически  связь изображается линией, соединяющей  две сущности (Рис.4 ):

     Рис. 4 Связь между сущностями

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

     Каждая  связь может иметь один из следующих  типов связи (Рис. 5):

     Рис. 5 Типы связей 

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

     Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней. Характерный пример такой связи приведен на Рис. 4.

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

     Каждая  связь может иметь одну из двух модальностей связи (Рис.6 ):

     Рис. 6 Модальность связи

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

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

     Связь может иметь разную модальность  с разных концов (как на Рис. 4).

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

     <Каждый  экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

     Каждая  связь может быть прочитана как  слева направо, так и справа налево. Связь на Рис. 4 читается так:

     Слева направо: "каждый сотрудник может  иметь несколько детей".

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

2.2. Пример построения ER-модели

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

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

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

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

ОТДЕЛ(ИМЯ_ОТДЕЛА),

СОТРУДНИК(ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ),

ДОЛЖНОСТЬ(ИМЯ_ДОЛЖНОСТИ, ОКЛАД),

и набор  связей РАБОТАЕТ_В с атрибутом  ставка между ними. Атрибут ставка может принимать значения из интервала ]0,1] (больше нуля, но меньше или равен  единице), он определяет какую часть  должностного оклада получает данный сотрудник(рис.7).  

Рис.7.ER- модель 

Каждый  n-арный набор связей можно заменить несколькими бинарными наборами.

связь не может быть одновременно обязательной, "супертип-подтип" или ассоциативной. 
 

2.3. Переход к реляционной модели данных

     Рассмотрим правила преобразования ER-модели в реляционную.

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

Каждый  атрибут сущности становится атрибутом  соответствующего отношения. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование названия отношений. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него).

Рис. 8.   Преобразование сущности СОТРУДНИК к отношению EMPLOYEE 

Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

Таблица 1. Свойства атрибутов отношения EMPLOYEE 

В каждое отношение, соответствующее подчиненной  сущности, добавляется набор атрибутов  основной сущности, являющейся первичным  ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).

Для моделирования  необязательного типа связи на физическом уровне у атрибутов, соответствующих  внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL).

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

4. Более сложные элементы ER-модели

     К числу более сложных элементов  модели относятся следующие:

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

Связи “many-to-many”. Иногда бывает необходимо связывать  сущности таким образом, что с  обоих концов связи могут присутствовать несколько экземпляров сущности (например, все члены кооператива  сообща владеют имуществом кооператива). Для этого вводится разновидность связи “многие-со-многими”.

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

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

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

Эти и  другие более сложные элементы модели данных “Сущность-Связи” делают ее существенно более мощной, но одновременно несколько усложняют ее использование. Конечно, при реальном использовании ER-диаграмм для проектирования баз данных необходимо ознакомиться со всеми возможностями.

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