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

  
 
 
 
 

 

Оглавление

 

Введение

 

     Принято считать, что реляционный подход к организации баз данных был заложен в конце 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. Экземпляр сущности - это конкретный представитель данной сущности.

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

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