Операции с данными, в сетевой модели данных:

• 
  ADD — создать запись в БД и, в зависимости от режима включения, либо включить ее в групповое отношение, в котором она объявлена дочерней, либо не включать ее ни в одно групповое отношение.
  
• 
  В ВКЛЮЧЕНИЕ ГРУППЫ — привязать существующую запись о ребенке к владельцу записи.
  
• 
  ПРИМЕЧАНИЕ — связать существующую запись о ребенке с другой записью владельца-владельца, находящейся в той же групповой связи.
  
• 
  Обновить — изменение значения элементов предварительно извлеченной записи.
  
• 
  ERROR — Извлечение записей последовательно по ключевому значению и использование групповых отношений — Вы можете переключаться с владельца на членов записи и с дочерней записи на владельца набора.
  
• 
  DELETECT — удаляет запись из базы данных. Если эта запись является владельцем групповых отношений, анализируется принадлежность к классу дочерних записей. Обязательные члены должны быть временно исключены из групповых отношений, фиксированные члены должны быть удалены вместе с владельцем, а необязательные члены остаются в базе данных.
  

ОТВЕТСТВЕННОСТЬ ЭКСКЛУДИНГ-ГРУППЫ — Отсоединить владельца записи от участника записи.

Модель реляционных данных

Модель реляций была предложена в 1970 году сотрудником IBM Э.Ф.Коддом (русский перевод статьи, в которой он впервые был описан в 1995 году в журнале СУБД N 1). В настоящее время эта модель является действующим стандартом, по которому ориентируются практически все современные коммерческие СУБД.

В реляционной модели достигается гораздо более высокая степень абстракции данных, чем в иерархической или сетевой модели. В приведенной выше статье Э.Ф.Кодды говорится, что «реляционная модель предоставляет средство описания данных только на основе их естественной структуры, т.е. без необходимости введения дополнительной структуры для целей машинного представления». Другими словами, представление данных не зависит от того, как они физически организованы. Это достигается за счет использования математической теории отношений (название «реляционная» происходит от английского отношения — «взаимосвязь»).

Полезно представлять отношения в виде таблиц. На рисунке 2 представлена таблица (соотношение степени 5), содержащая некоторую информацию о работниках гипотетического предприятия. Ряды таблицы соответствуют моторизованным поездам. Каждая строка на самом деле является описанием реального объекта (в данном случае сотрудника), характеристики которого содержатся в столбцах. Можно провести аналогию между элементами реляционной модели данных и элементами модели «предметного взаимодействия». Отношения соответствуют наборам сущностей, а кортежи — сущностям. Поэтому, как и в модели взаимодействия сущностей, столбцы таблицы, представляющие реляционную связь, называются атрибутами.

---

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

На одном и том же домене можно определить несколько атрибутов одного и того же отношения и даже атрибуты разных отношений. В примере, показанном на рис.2, атрибуты «зарплата» и «бонус» определены на домене «деньги». Поэтому понятие домена имеет семантическую нагрузку: данные могут считаться сопоставимыми только в том случае, если они относятся к одному и тому же домену. Например, в рассматриваемом примере сравнение атрибутов «номер индикатора» и «вознаграждение» является семантически некорректным, даже если они содержат данные одного и того же типа.

Набор имен пар «имя атрибута — имя домена» называется схемой отношений. Сила этого набора называется степенью или «арнити» отношений. Набор именованных схем взаимоотношений представляет собой схему базы данных.

Атрибут, значение которого однозначно идентифицирует кортежи, называется ключом (или просто ключом). В нашем случае ключом является атрибут «номер индикатора», так как его значение уникально для каждого сотрудника компании. Если кортежи идентифицируются только путем объединения значений нескольких атрибутов, считается, что связь имеет составной ключ.

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

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

Например, отношения между ПОСТАВЩИКОМ и ЗАКАЗЧИКОМ устанавливаются путем копирования первичного ключа «DELIVER_Number» из первого отношения во второе.

Для получения списка сотрудников данного подразделения необходимо:

• 
  из таблицы отделов установить значение атрибута «Номер отдела» в соответствии с данным «Название отдела».
  
• 
  Из таблицы ИСТОЧНИКИ выберите все записи, значение атрибута «Номер отдела» которых совпадает со значением, полученным на предыдущем шаге.
  

---

Чтобы узнать, в каком отделе работает сотрудник, необходимо выполнить обратную процедуру:

• 
  Определите «Номер_отдела» из таблицы STRUCTURE.
  
• 
  для полученного значения мы находим набор данных в таблице ПОЛУЧАТЕЛЬСТВА.
  

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

Свойства отношений.

Никаких двойных кортежей. Это свойство означает, что каждый кортеж имеет первичный ключ. Для каждого отношения, по крайней мере, полный набор его атрибутов является первичным ключом. Однако при определении первичного ключа должно выполняться требование «минимума», т.е. он не должен содержать тех атрибутов, которые можно отбрасывать, не затрагивая основное свойство первичного ключа — уникальное определение кортежа.

Отсутствие порядка в кортеже.

Отсутствие стойкости атрибутов. Имя атрибута всегда используется для ссылки на значение атрибута.

Атомность значений атрибутов, т.е. несколько значений (отношений) не могут содержаться под значениями домена.

Объектно-ориентированная СУБД

Объектно-ориентированная база данных (Object Oriented Database, OBD) — база данных, в которой данные моделируются как объекты, их атрибуты, методы и классы.

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

Структура объектной модели описывается с использованием трех ключевых понятий:

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

---

Для сохранения целостности объектно-ориентированный подход предоставляет следующие инструменты:

• 
  автоматическое наследование
  
• 
  возможность объявлять «скрытыми» некоторые поля данных и методы объекта, которые не видны другим объектам; такие поля и методы используются только методами самого объекта
  
• 
  Управление целостностью активов
  

В отличие от реляционных баз данных, в объектно-ориентированных базах данных хранятся не записи, а объекты.

Подход ОП является более продвинутым средством представления реального мира, чем реляционная модель:

• 
  естественное представление данных. В реляционной модели все отношения относятся к одному уровню, что затрудняет трансформацию иерархических отношений модели «коммуникации сущностей» в реляционную модель. О-модель может быть просмотрена слоями на разных уровнях абстракции.
  
• 
  Можно определить новые типы данных и операции с ними.
  

В то же время, модель OO имеет ряд недостатков:

• 
  Нет мощных непроцедурных средств для извлечения объектов из базы. Все запросы должны быть написаны на процедурных языках, проблема их оптимизации лежит на программисте.
  
• 
  Вместо чисто декларативных ограничений целостности (таких как явное объявление ключей первичных и внешних таблиц реляций с использованием ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров, код процедуры должен быть написан для обеспечения внутренней целостности.
  

Очевидно, что эти два недостатка связаны с отсутствием разработанных средств манипулирования данными. Эта проблема решается двумя способами — путем расширения языков OL в сторону управления данными (стандарт ODMG) или путем добавления свойств объектов в реляционной СУБД (SQL-3, а также так называемой объектно-реляционной СУБД).

Заключение

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

---

Цель базы данных — помочь людям и организациям отслеживать определенные вещи.

Список литературы

1. 
   АткинсонМ.,БансилонФДеВиттДиДиттрихК., МайерД.ЗдоникС. Манифест объектно-ориентированных систем баз данных.DBMS № 4, 2001
   
2. 
   Бойко В.В., Савинков В.М. Проектирование баз данных для информационных систем. -M. : «Финансы и статистика», 2006.
   
3. 
   N.Wirth. Алгоритмы и структуры данных.-М. : «Мир», 2005.
   
4. 
   Медников А.Ю. Объектно-ориентированные базы данных сегодня или завтра? Открытые системы N 4.2004
   
5. 
   Ким выиграл объектно-ориентированную технологию базы данных. Открытые системы N 4, 1992
   
6. 
   Шибуя М. Ямамото Т. Алгоритмы обработки данных.
   
7. 
   ПшиялковскийВ. Новая одежда, знакомая с СУБД: Объект, переданный нам реальностью. СУБД N4, 2004
   
8. 
   Кузнец С. Д. Основы баз данных — 2-е издание — М.: Интернет-Университет информационных технологий; БИНОМ. Лаборатория знаний, 2004 г. — 484 с.
   

---

Смотрите также файлы

• Порядок выполнения ргр.docx

• Сценарийобщешкольного новогоднего праздника для учащихся 14 классовЗимние приключения Музыка 1 Выход ведущей.docx

• Быстрый переход Определение предела последовательности. Подпоследовательность. Частичный предел.docx

• Отчет о прохождении производственной практики, реализуемой в форме практической подготовки.docx

• 1. Киберпреступность и кибербезопасность социальная инженерия.docx