Главная страница
Навигация по странице:

  • 2.Модель типа объект/отношение

  • Общий подход и проблемы.

  • 3.Виды связей.

  • Диаграммы объектов / связей.

  • Лекция2. Лекция 2 Схемы уровня представлений и модель типа объектотношение. План Уровни абстракции в субд


    Скачать 47.1 Kb.
    НазваниеЛекция 2 Схемы уровня представлений и модель типа объектотношение. План Уровни абстракции в субд
    Дата10.10.2022
    Размер47.1 Kb.
    Формат файлаdocx
    Имя файлаЛекция2.docx
    ТипЛекция
    #724582

    Лекция №2: Схемы уровня представлений и модель типа объект/отношение.
    План:

    1. Уровни абстракции в СУБД

    2. Модель типа объект/отношение

    3. Виды связей.


    Абстрагирование – отбрасывание лишних элементов в моделях объектов реального мира с выделением основных объектов и элементов. Цель любой информационной системы – обработка данных об объектах реального мира. В широком смысле слова база данных – это совокупность сведений о конкретных объектах реального мира в какой–либо предметной области. Таким образом, база данных это информационная модель предметной области. Каждый конечный пользователь должен получать возможность взаимодействовать с информационной системой на понятном ему языке, в соответствии с его представлением о предметной области. Представление каждого пользователя описывает явления и объекты из предметной области лишь с некоторой точностью, необходимой для его деятельности. Получается такое представление путем выделения основных, с точки зрения пользователя, явлений, объектов, свойств и отбрасыванием второстепенных. Процесс отвлечения от ряда свойств и отношений изучаемого явления с одновременным выделением интересующих исследователя свойств называется абстрагированием. Реализуется представление конечного пользователя в информационной системе с помощью приложений. Так как обычно имеется несколько пользователей информационной системы, то в БД должны быть реализованы несколько представлений. Образы объектов и явлений реального мира, выделенные на основании представлений пользователей, записываются в памяти ЭВМ в цифровом виде. При этом возникает задача разработать такую архитектуру баз данных, которая позволила бы весь период эксплуатации БД обеспечивать стабильное развитие и, при необходимости, простую модификацию баз данных, разрабатываемых с помощью различных СУБД. Следовательно, перед разработчиками архитектуры БД стояла задача, аналогичная задаче стандартизации архитектуры компьютерных сетей. Решения этих задач также аналогичные – использовать многоуровневую архитектуру, что позволяет развивать и совершенствовать одни уровни БД достаточно независимо от других.

    Самая жизнеспособная архитектура организации базы данных была предложена группой ANSI/X3/SPARC Study Group, которая была организована в 1972 г. комитетом Standards Planning and Requirements Committee (SPARC) института American National Standards Institute on Computers and Information Processing (ANSI/X3). Эта архитектура имеет трехуровневую систему организации базы данных.
    Таким образом, существуют три уровня абстракции в архитектуре базы данных:

    • представление (внешняя модель базы данных);

    • концептуальная база данных (КБД);

    • физическая база данных (ФБД).




    Внешний уровень

    Логический

    уровень

    Внутренний

    (физический)

    уровень

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

    1. Внешняя модель или уровень представления. На этом уровне предметная область (т.е. та область деятельности, в которой осуществляется разработка данной системы) описывается будущим пользователем БД. Каждый пользователь описывает свое представление о предметной области. При этом, описывается: какие объекты важны в работе пользователя, какими свойствами они обладают, связи между объектами, прочие правила взаимодействия объектов.

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

    • язык, описывающий деревья (иерархическая модель);

    • язык сетей, как класса графов (сети, сетевая модель).

    • язык отношений (реляционная модель);

    • ER – модели, как вариант языка сетевой модели.

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

    Разработка внешних представления и концептуальной модели является ядром проблемы проектирования базы данных. В процессе проектирования активно используются языки моделей данных СУБД и понятия из предметной области. Для реализации базы данных СУБД должна иметь средства как определения и поддержки базы данных на всех уровнях, так и развитые интерфейсы для обеспечения взаимодействия всех трех уровней между собой. Последние интерфейсы называют отображениями одного уровня архитектуры на другой.
    2.Модель типа объект/отношение
    Модель БД типа объект/отношение могут быть использованы на всех уровнях абстракции.

    Особенности модели. Ее преимущества и недостатки.

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

    Общий подход и проблемы. Для того чтобы описать представление предметной области необходимо задать множество объектов реального мира. Объект – семантическое понятие, которое может быть полезно при обсуждении устройства реального мира. Т.е. нечто существенное, полезное для описания предметной области. Можно дать другое определение: объект это сущность реального мира. Объекты – не обязательно должны быть материальными. Важным является только существенность и различимость каждого объекта от других.

    Пример: объектами являются: сотрудник, пассажир, самолет, деталь и т.д. 

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

    Пример: подчиненный сотрудник  основной сотрудник.

    Различают тип объекта и экземпляр объекта

    Пример: тип – сотрудник; экземпляр – Иванов.

    Объект обладает рядом свойств, которые иногда называют атрибутами объекта. Различают тип атрибута и значение атрибута. В информационной модели объект представляется значениями своих атрибутов. Совокупность значений атрибутов объекта является его информационной моделью.

    Пример: объект — сотрудник, его атрибуты: ФИО, дата рождения...

    Для определения нового типа объекта иногда используют понятие подтипа. Например, пилот – есть подтип объекта сотрудник. Пилот обладает всеми свойствами сотрудника и, кроме того, свойством - список разрешенных для управления самолетов. Очевидно, что механизм подтипов является прообразом наследования из ООП.

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

    Пример: объект студент, ключ – номер зачетной книжки.

    3.Виды связей. Между объектами могут возникать связи.

    Пример: между объектами деталь и поставщик может возникнуть связь – деталь_поставляется_поставщиком (для каждого экземпляра поставщика ставится в соответствие список деталей, которые он поставляет).

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

    Рассмотрим виды связей на примере базы данных «Хирургическое отделение больницы». Выделим четыре типа объектов: Место_в_палате, Палата, Пациент, Хирург.

    Между объектами могут возникать следующие связи:

    • один к одному 1:1 (Пациент - Место_в_палате);

    • один к многим 1:n, или, как вариант - многие к одному n:1 (Палата - Место_в_палате);

    • многие к многим n:n (Пациент - Хирург).

    Диаграммы объектов / связей. Диаграмма – графическое изображение структуры БД с использованием ER-модели.




    Объект - Связь- Атрибут -




    Пример . ER- диаграмму рассмотрим на примере БД аэропорта.

    Связи :

    А – пассажир купил билет

    В – выполняется

    С – есть

    D – допущен к

    Е – типа

    F – назначен на


    написать администратору сайта