Что такое сущность в бд

Понятие ER-модели. Понятие сущности (entity). Атрибуты. Виды атрибутов

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

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

• поиск эффективных алгоритмов;
• подбор надлежащих структур данных;
• отладка и тестирование сложного кода;
• дизайн и удобство интерфейса приложения.

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

Чтобы облегчить процесс разработки (проектирования) базы данных, используются так называемые семантические модели данных. Для разных видов баз данных наиболее известной есть ER-модель данных (Entity-Relationship model).

2. Что такое ER-модель (Entity-relationship model)? Для чего нужно разрабатывать ER-модель?

ER-модель (Entity-relationship model или Entity-relationship diagram) – это семантическая модель данных, которая предназначена для упрощения процесса проектирования базы данных. Из ER-модели могут быть порождены все виды баз данных: реляционные, иерархические, сетевые, объектные. В основе ER-модели лежат понятия «сущность», «связь» и «атрибут».

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

ER-модель – это представление базы данных в виде наглядных графических диаграмм. ER-модель визуализирует процесс, который определяет некоторую предметную область. Диаграмма «сущность»-«связь» – это диаграмма, которая представляет в графическом виде сущности, атрибуты и связи.

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

3. Что такое сущность в базе данных? Примеры

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

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

• книга;
• поставщик;
• размещение в магазине.

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

• студенты (ученики);
• преподаватели;
• группы;
• дисциплины, которые изучаются.

4. Какие существуют разновидности типов сущностей? Обозначение типов сущностей в ER-модели

В модели «сущность»-«связь» различают две разновидности типов сущностей:

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

На рисунке 1 изображены обозначения слабого и сильного типа сущности в ER-модели.

Рис. 1. Обозначение сильного и слабого типов сущности

5. Для чего предназначены атрибуты? Виды атрибутов. Обозначение атрибутов на ER-модели

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

Различают следующие виды атрибутов:

• простые атрибуты. Это атрибуты, которые могут быть частью составных атрибутов. Эти атрибуты состоят из одного компонента. Например, к простым атрибутам можно отнести: код книги в библиотеке или курс обучения студента в учебном заведении;
• составные атрибуты. Это атрибуты, которые состоят из нескольких простых атрибутов. Например, адрес проживания может содержать название страны, населенного пункта, улицы, номера дома;
• однозначные атрибуты. Это атрибуты, которые содержат только одно единственное значение для некоторой сущности. Например, атрибут «Номер зачетной книги» для типа сущности «Студент» есть однозначным, так как студент может иметь только один номер зачетной книги (одно значение);
• многозначные атрибуты. Это атрибуты, которые могут содержать несколько значений. Например, многозначный атрибут «Номер телефона» для сущности «Студент», так как студент может иметь несколько номеров телефона (домашний, мобильный и т.д.);
• произвольные атрибуты. Это атрибуты, значение которых формируется на основе значений других атрибутов. Например, текущий курс обучения студента можно вычислить на основе разности текущего года обучения и года поступления студента в учебное заведение (если студент не имел проблем с учебой и хорошо учил дисциплину «Организация баз данных и знаний»).

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

Рисунок 2. Представление атрибутов на диаграммах ER-модели

6. Как типы сущностей и атрибуты ER-модели реализуются в реальных базах данных и управляемых ими программах?

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

• выбрать в качестве источника данных известную технологию (например Microsoft SQL Server, Oracle Database, Microsoft Access, Microsoft ODBC Data Source и т.п.), которая уже исследована, протестирована, стандартизирована и имеет огромный набор средств управления базой данных;
• разработать собственный формат базы данных и реализовать методы ее обработки, а взаимодействие с известными источниками данных реализовать в виде специальных команд наподобие Импорт/Экспорт. В этом случае придется собственноручно программировать всю рутинную работу по ведению и обеспечению надежной работы базы данных;
• реализовать объединение двух вышеприведенных подходов. Современные средства разработки программного обеспечения имеют мощный набор библиотек для обработки сложных наборов и визуализации данных в них (коллекции, массивы, компоненты визуализации и т.п.).

Если база данных реализуется в известных реляционных СУБД (например Microsoft Access, Microsoft SQL Server и т.п.), то типы сущностей представляются таблицами. Атрибуты из ER-модели соответствуют полям таблицы. Одна запись в таблице базы данных представляет один экземпляр сущности.

Каждый вид атрибута реализуется следующим образом:

• простой атрибут или однозначный атрибут может быть представлен доступным набором базовых типов, которые есть в любом языке программирования. Например, целочисленные атрибуты представляются типом int , integer , uint и т.д.; атрибуты содержащие дробную часть могут быть представлены типом float , double ; строчные атрибуты типом string и т.д.;
• составной атрибут – это объект, который включает в себя несколько вложенных простых атрибутов. Например, в СУБД Microsoft Access составной атрибут некоторой таблицы может формироваться на основе набора простых типов (полей). В языках программирования объединение полей реализуется структурами или классами;
• многозначный атрибут может быть реализован массивом или коллекцией простых или составных атрибутов;
• произвольный атрибут реализуется дополнительным полем, которое вычисляется при обращении к таблице. Такое поле называется вычислительным полем (calculated field) и формируется на основе других полей таблицы;
• атрибут, который есть первичным ключом может быть целочисленным, строчным или иного порядкового типа. В этом случае, значение каждой ячейки таблицы, которая соответствует первичному ключу, есть уникальным. Наиболее часто, в качестве первичного ключа выступает целый тип ( int , integer ).

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

7. Пример фрагмента ER-модели для типа сущности «Студент»

Приведенный пример демонстрирует фрагмент ER-модели для типа сущности «Студент».

Рисунок 3. Фрагмент ER-модели для типа сущности «Студент»

На вышеприведенном рисунке объявляются следующие атрибуты, которые в СУБД (программе) могут иметь следующие типы:

• атрибут Первичный ключ – есть уникальным целочисленным значением которое формируется автоматически. В СУБД это есть поле-счетчик;
• атрибут Год вступления – простой атрибут, который можно реализовать целочисленным значением ( int , integer );
• атрибут Номер телефона – многозначный атрибут, который может быть реализован как массив или коллекция и т.п.;
• атрибут Номер зачетной книжки – простой атрибут, который можно реализовать как строку символов, поскольку номер зачетной книжки кроме цифр может содержать и буквы;
• атрибут Страна , Город , Улица , Номер дома – это атрибуты, которые образуют составной атрибут Адрес . Все эти атрибуты могут быть строчного (текстового) типа ( string , Text );
• атрибут Фамилия , Имя , Отчество – это простые атрибуты, которые являются частью составного атрибута Имя студента . Все эти атрибуты могут быть строчного (текстового) типа ( string , Text );
• атрибут День рождения – простой атрибут типа Дата ( DateTime );
• атрибут Возраст студента – вычисляемое поле, которое определяется как разность текущей (системной) даты и значения атрибута День рождения .

Связанные темы

• Подтипы сущностей. Супертип. Пример. Преимущества и недостатки применения подтипов сущностей
• Понятие связи в ER-модели. Мощность связи. Типы связей. Примеры

Модель сущность-связь

Домен не указывает конкретный физический тип, однако позволяет указать, какие атрибуты будут иметь одинаковый тип в физической модели. Так, например, атрибуты $FirstName$ и $LastName$ сущности $Student$ будут обладать одним физическим типом.

Типы доменов:

• Простой — атомарное значение, например, $id$
• Составной — состоящий из нескольких значений, например, passport

Свойства атрибутов:

Обозначение	Свойство
M	Обязательное (англ. mandatory)
O	Необязательное (англ. optional)
PK	Основной ключ (англ. primary key)
Kn	Дополнительный ключ $n$ (англ. key)

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

Связи

Пример связи

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

• Имя
• Связываемые сущности и их роли
• Тип связи (задается типами концов)

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

Типы концов:

Тип	Обозначение
Один
Много
Обязательный
Необязательный

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

Связь	Значение	По умолчанию
	Многие ко многим	Единственность, необязательность
	Один ко многим	Единственность, обязательность
	Один к одному	Единственность, обязательность

Замечание: В дальнейшем будем считать, что значениями по умолчанию будет «один» и «необязательный».

Ассоциации

Определение:

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

Графическое обозначение ассоциации

• Ассоциация обозначается прямоугольником с закругленными краями
• Может содержать не ключевые атрибуты
• Имеет произвольное количество концов с произвольными ролями и типами

Пример с ассоциацией

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

Как понять, что использовать: ассоциацию, связь или сущность?

• Если нужно два конца и нет нагруженности, используем связь
• Если нужно идентифицировать, используем сущность, поскольку связь не идентифицируется из-за отсутствия ключевых элементов
• Иначе используется ассоциация

Многосторонние ассоциации

Пример неоднозначности интерпретации связей

Многостороннюю ассоциацию можно интерпретировать по-разному. Так, например, на рисунке может быть обозначено следующее:

• У каждого контракта есть один поручитель
• Можно быть поручителем у ровно одного контракта

Ограничение по Чену (англ. Chen-like, Look-across)		Зафиксировав остальные сущности, получаем ограничение на рассматриваемую. У каждого контракта есть поручитель.
Ограничение по Мерис (англ. Merise-like, Look-here)		Ограничение непосредственно на сущность. Можно быть поручителем у одного контракта.

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

Выразительная мощность ограничений

• Для ассоциаций с двумя концами:
  • Чен = Мерис = Обобщенные
  • Чен + Мерис = Обобщенные
  • Чен + Мерис < Обобщенные

  Слабые сущности

  Определение:

  Слабой сущностью называется сущность, у которой недостаточно атрибутов для идентификации.

  Слабая сущность обозначается прямоугольником с двойной границей.

  Определение:

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

  

  Пример слабой сущности

  Идентифицирующая связь обозначается двойной сплошной линией.

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

  Альтернативные нотации

  Выше рассматривалась нотация Crow’s foot, предложенная Гордоном Эверестом.

  Нотация Питера Чена

  Модель Сущность-связь была предложена Питером Ченом в 1976 году, им же была предложена следующая графическая нотация:

  

  UML-нотация

  Для каждой таблицы явно подписывается, что она обозначает (ассоциацию, сущность и т.д.). Ограничения прописываются в виде $i..k$ (например, $1..n$), это позволяет наложить ограничение $2..n$, что было невозможно в Crow’s foot.

  

  Object Definition Language

  Позволяет задавать схему базы данных кодом.

  Рассмотрим пример. У студента есть идентификатор Id , имя Name , а также ссылка на группу group . Явно указываем, что противоположностью этой ссылки является соответствующее поле класса Group : inverse Group::students .

  У группы есть Id и смножество студентов students , учащихся в группе. Указываем, что у студентов ссылка хранится в поле group .

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

  class Student < int Id; string Name; Group group inverse Group::students; >class Group < int id; Setstudents inverse Student::group; >

  Что такое сущность в бд

  Модель «сущность — связь» (или ER -модель) представляет собой способ логического унифицированного представления данных некоторой предметной области. Хотя, как мы увидим далее, эта модель очень напоминает систему связанных друг с другом таблиц, в действительности это совершенно общее представление. Эта модель может быть преобразована к любой из существующих конкретных моделей данных: иерархической, сетевой, реляционной, объектной. Существенно, что ER -модель позволяет представлять только данные, но не действия, которые с ними могут производиться, поэтому она используется лишь для проектирования структуры хранимых данных. Поскольку многие понятия, которые мы будем разбирать в связи с моделью «сущность — связь» были нами рассмотрены в основах реляционных баз данных (параграфы 1.1,1.2,1.3), будем опираться на эти знания.

  Достоинствами данной модели являются

  · Использование естественного языка.

  Сущность XE «Сущность» это собирательное понятие, некоторая абстракция реально существующего объекта, процесса, явления или некоторого представления об объекте, информацию о котором требуется хранить в базе данных.

  Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД , а экземпляром – Москва, Киев и т.д. Предполагается, что гарантировано отличие экземпляров одного типа сущности друг от друга. Данное требование вполне аналогично требованию отсутствия в таблице тождественных строк. В дальнейшем, однако, там, где это не может вызвать неоднозначного прочтения, мы не будем различать типы и экземпляры, а будем просто использовать термин «сущность». Принято выражать (именовать) сущность существительным или существительным с характеризующим его прилагательным (СТУДЕНТ, ДЕКАНАТ, ВЫПУСКАЮЩАЯ КАФЕДРА и др.).

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

  Стержневая сущность XE «Стержневая сущность» .

  Стержневая (сильная) XE «Сильная сущность» сущность – независящая от других сущность. Стержневая сущность не может быть ассоциацией, характеристикой или обозначением (см. ниже).

  Ассоциативная сущность XE «Ассоциативная сущность» (или ассоциация) выражает собой связь «многие ко многим» между двумя сущностями. Является вполне самостоятельной сущностью. Например, между сущностями МУЖЧИНА и ЖЕНЩИНА существует ассоциативная связь, выражаемая ассоциативной сущностью БРАК.

  Характеристическую сущность XE «Характеристическая сущность» еще называют слабой сущностью. Она связана с более сильной сущностью связями «один ко многим» и «один к одному». Характеристическая сущность описывает или уточняет другую сущность. Она полностью зависит от нее и исчезает с исчезновением последней. Например, сущность Зарплата является характеристикой конкретных работников предприятия и не может в таком контексте существовать самостоятельно – при удалении экземпляра сущности Работника должны быть удалены и экземпляры сущности Зарплата, связанные с удаляемым работником.

  Обозначение XE «Обозначение» это такая сущность, с которой другие сущности связаны по принципу «многие к одному» или «один к одному». Обозначение, в отличие характеристики является самостоятельной сущностью. Например, сущность Факультет обозначает принадлежность студента к данному подразделению института, но является вполне самостоятельной.

  Любой фрагмент предметной области может быть представлен некоторым набором сущностей и связями между ними. Например, рассматривая предметную область ФАКУЛЬТЕТ можно выделить следующие основные сущности: СТУДЕНТ, КАФЕДРА, СПЕЦИАЛЬНОСТЬ, ДЕКАНАТ, ГРУППА, ПРЕПОДАВАТЕЛЬ, ЭКЗАМЕН . На первом этапе создания ER -модели данных следует выделить все сущности, которые предполагается описывать исходя из постановки задачи. Лишний раз подчеркнем, что сущностью может быть не только некоторый материальный объект, но и некоторый процесс, например ЭКЗАМЕН, ЛЕКЦИЯ . Сущностью может быть и некоторая количественная и качественные характеристики объекта: УЧЕНОЕ ЗВАНИЕ, СТАЖ и др. Все в действительности зависит от постановки задачи и от нашего анализа предметной области.

  Основные понятия

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

  Система диаграмм

  Следует заметить, что в настоящее время разработано несколько различных графических методов представления диаграмм в модели «сущность — связь». Рассмотрим один из возможных подходов, в основе которого лежат диаграммы Чена.

  Таблица 1.6. Обозначения для ER- модели

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

  Атрибут сущности. Вместо имени атрибута можно указать многоточие «…», что будет обозначать группу атрибутов.

  Атрибут сущности, являющийся первичным ключом.

  Обозначает связь, между двумя сущностями.

  Ассоциативная сущность (связь «многие ко многим»).

  Обозначение сущности вида «характеристика».

  Показывает сущность вида «обозначение».

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

  Правила порождения

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

  Таблица 1.7.Правила соответствия

  Тип бинарной связи

  Элементы реляционной базы данных

  Связь «один к одному», характеристики

  Для каждой сущности строится своя таблица. Связь между таблицами «один к одному».

  Связь «один к одному», характеристики

  Строится одна таблица, структура которой состоит из атрибутов обеих сущностей. В качестве первичного ключа берется ключ одной из сущностей.

  Связь «один к одному», характеристики

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

  Связь «один ко многим», характеристики

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

  Связь «один ко многим», характеристики

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

  Связь «многие ко многим», характеристики

  Любая связь такого типа строится на основе трех таблиц (см. пар. 2, Многие ко многим).

  Правила порождения позволят легко перейти от логической модели данных к физической модели.

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

  О диаграммных техниках, используемых при построении информационных систем

  Функциональные диаграммы

  Функциональное моделирование основывается на техниках SADT XE » SADT » и IDEF XE » IDEF » . SADT была предложена Дугласом Россом в середине 1960-х годов. Военно-воздушные силы США использовали методику SADT в своей программе ICAM XE » ICAM » ( Integrated Computer Aided Manufacturing – интеграция компьютерных и промышленных технологий) и назвали ее IDEF В рамках технологии SADT было разработано несколько графических языков моделирования:

  ■ IDEF 0 – для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем.

  ■ IDEF 1 – для документирования информации о производственном окружении систем.

  ■ IDEF 2 – для отображения поведения систем во времени.

  ■ IDEF 3 – для моделирования бизнес процессов.

  ■ IDEF4 – объектно-ориентированное моделирование.

  ■ IDEF 5 – моделирование наиболее общих (онтологических) закономерностей системы.

  Методология IDEF — SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели какой-либо предметной области. Центральным понятием этой методологии является понятие функции XE «Функция» . Иногда используют и другие термины: деятельность или процесс. Под функцией понимается некоторое действие или набор действий, которые имеют определенную цель и приводят к конкретным результатам. Определенная функция на диаграмме обозначается прямоугольником. На диаграмме используются также стрелки, которые обеспечивают связь между различными функциями (обеспечивают интерфейсы), связывая их в конечном итоге в единую систему, моделирующую предметную область. В диаграммах используются стрелки четырех видов, их называют интерфейсными дугами:

  ■ I ( Input ) – вход, т.е. все что является исходным материалом для данной функции. Стрелка входит слева в прямоугольник, обозначающий данную деятельность.

  ■ O ( Output ) – результат выполнения функции. Стрелка выходит справа из прямоугольника, обозначающего функцию.

  ■ C ( Control ) – ограничения данной функции (все, что ограничивает функцию). Стрелка входит в прямоугольник сверху.

  ■ M ( Mechanism ) – механизм, используемый в данной функции. Стрелка входит снизу в прямоугольник — функцию.

  На Рис. 1.15 представлен общий вид фрагмента диаграммы, изображенной по методологии SADT .

  Рис. 1.15. Общий вид функциональной диаграммы

  Рис. 1.18. Диаграмма SADT , полученная из общей диаграммы (см. Рис. 1.17) посредством детализации

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

  ■ Логическая связность. Обусловлена тем, что функции или данные относятся к одному классу.

  ■ Временная связность. Такой тип связности возникает, когда функции выполняются параллельно в одно и тоже время.

  ■ Процедурная связность. Тип связности возникает, когда функции выполняются в одной и той же части процесса.

  ■ Коммуникационная связность. Возникает, когда блоки (функции) используют одни и те же данные.

  ■ Последовательная связность. Возникает, когда выход (выходная дуга) одной функции является одновременно входными данными для другой функции.

  ■ Функциональная связность. Связность возникает, когда одна функция воздействует на другую через интерфейсные дуги управления (на Рис. 1.18 блок 1 воздействует на остальные блоки как раз через дуги управления).

  Диаграммы потоков данных

  В основе данной методологии лежит метод диаграмм потоков данных ( DFD XE » DFD » — Data Flow Diagram ). Данные диаграммы призваны описывать процессы преобразования информации от ее ввода в систему до выдачи пользователю. Как и для диаграмм SADT здесь мы также имеем дело с целой иерархией диаграмм, в которой диаграммы нижнего уровня детализируют диаграммы верхнего уровня. Диаграммы верхнего уровня определяют основные процессы и подсистемы информационной системы с внешними входами и выходами. Далее путем декомпозиции диаграммы детализируются. В результате возникает иерархия диаграмм, на самом нижнем уровне которой описаны элементарные процессы. Основными компонентами диаграмм DFD являются:

  ■ Системы и подсистемы.

  Рис. 1.19. Внешняя сущность в потоковых диаграммах

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

  Рис. 1.20. Обозначение подсистемы в потоковой диаграмме

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

  Рис. 1.21. Обозначение процесса в потоковой диаграмме

  Процесс в модели DFD представляет собой некоторое преобразование входного потока данных в выходной. Под процессом можно понимать и оператора ЭВМ и программу, и работу целого отдела. На диаграмме процесс изображается как подсистема в виде прямоугольника (см. Рис. 1.21). Номер процесса является его идентификатором и состоит из номера процесса или подсистемы верхнего уровня и собственно номера процесса. Имя процесса должно содержать глагол в неопределенной форме и четко определять, что данный процесс делает. Наконец в имени процесса должен быть обозначен объект, который и реализует данный процесс.

  Рис. 1.22. Накопитель в потоковой диаграмме

  Под накопителем понимается некоторое устройство, используемое для хранения информации. Способы помещения и извлечения данных из накопителя могут самые разные. Накопитель данных на диаграмме изображается в виде прямоугольника (см. Рис. 1.22), разделенного на два отсека. В первом отсеке должен стоять номер накопителя, начинающийся с буквы D , во втором его имя. Имя накопителя должно быть достаточно информативным для использования его в дальнейших разработках. Разумеется при разработке информационной системы в конечном итоге под накопителем, понимается конкретная база данных.

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

  Рис. 1.23. Пример потоковой диаграммы, описывающей некоторые процессы подсистемы «Абонент»

  UML диаграммы

  Как и другие языки моделирования сложных систем, язык UML зиждется на трех принципах:

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

  ■ Многомодельность – любая достаточно сложная система не может быть полностью описана только одной моделью.

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

  Всего в языке UML существует одиннадцать типов диаграмм. Каждая из диаграмм призвана конкретизировать различные представления о рассматриваемой системе. Перечислим типы диаграмм:

  ■ Диаграммы вариантов использования.

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

  Классом XE «Класс» в языке UML будем называть именованное описание множества однородных объектов, имеющие одинаковые атрибуты, операции XE «Операции» , отношения с другими объектами и семантику.

  Атрибут класса XE «Атрибут класса» — именованное свойство класса, описывающее множество значений, которые принимают экземпляры этого свойства.

  Операцией класса XE «Операция класса» будем называть именованную услугу, которую можно запросить у любого экземпляра данного класса.

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

  Определение зависимости XE «Зависимости» .

  Связь между двумя классами называю зависимостью, если изменение в спецификации одного класса может повлиять на поведение другого класса.

  Определение обобщения XE «Обобщения» .

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

  Общий класс при наследовании называется родителем, предком или суперклассом XE «Суперкласс» , а частный класс – потомком. Например, при анализе такой системы как школа, можно выделить суперкласс Человек, в который будут входить такие классы – потомки, как учителя, административные работники школы, ученики, родители учеников. В дальнейшем класс учителей можно рассматривать как суперкласс по отношению к обычным учителям и классным руководителям.

  Определение ассоциации XE «Ассоциации» .

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

  Ассоциативная связь может характеристики:

  ■ Роли связи XE «Роли связи» . Для каждого класса, участвующего в ассоциативной связи могут быть указаны роли. Например, для связи между классами Учителя и Ученики можно указать роли: обучающий и обучаемый.

  ■ Кратность связи XE «Кратность связи» . Кратность определяет, сколько объектов данного класса может или должно участвовать в данной связи. Например, кратность 0..1 говорит, что не все экземпляры класса могут участвовать в данной связи, но в каждом экземпляре связи может участвовать только один объект класса.

  ■ Агрегация XE «Агрегация» . Если в ассоциативной связи один из классов выступает в роли «целого», а второй в роли «части целого», то такой типа связь называется агрегатной связью. В ней один из классов играет главную, а другой (другие) подчиненную роль. Сильная агрегатная связь называется композицией XE «Композиция» . При такой связи уничтожении главного класса приводит к уничтожению подчиненного класса.

  В диаграммах классов могут также указываться ограничения, которые затем должны поддерживаться в базах данных. Ограничения могут выражаться предложениями на естественном языке, но могут записываться на специальном языке OCL XE » OCL » ( Object Constraint Language – язык объектных ограничений). Язык OCL является подмножеством языка UML . Это формальный язык, который позволяет выразить логику ограничений, накладываемых на отдельные элементы диаграмм.

  Рис. 1.24. пример простейшей UML -диаграммы

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

  [1] Разумеется, читатель должен понимать, что речь идет о классе (наборе) сущностей.

  Что такое сущность в бд

  1. Представление данных с помощью модели «сущность-связь».

  Удобным инструментом представления данных является модель «сущность-связь». Из модели «сущность-связь» могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей. Основными составляющими этой модели являются: типы сущностей, атрибуты, типы связей. Типы сущностей – объект или концепция, которая характеризуется на данном предприятии и имеет независимое существование. Типы сущностей бывают реальными (сотрудник, станок) и абстрактными (сущность расписания)

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

  Число сущностей может быть ассоциировано через набор связей с другой сущностью. Их называют степенью связи. Рассмотрение степеней особенно полезно для бинарных связей. Могут существовать следующие степени бинарных связей:

  один к одному (обозначается 1 : 1 ). Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью.

  один ко многим ( 1 : n ). В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью.

  много к одному (n : 1 ) . Эта связь аналогична отображению 1 : n.

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

  Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью (иногда сущность x называют «слабой», а «сущность» y — сильной).

  Прямоугольники обозначают сущности, а ромб — связь.

  

  2.Диаграмма «сущность-связь».

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

  

  Набор независимых сущностей

  

  Набор зависимых сущностей

  

  Атрибут

  

  Ключевой атрибут

  

  Набор связей

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

  В процессе построения диаграммы можно выделить несколько очевидных этапов:

  1. Идентификация представляющих интерес сущностей и связей.

  2. Идентификация семантической информации в наборах связей (например, является ли некоторый набор связей отображением 1:n).

  3. Определение кардинальностей связей.

  4. Определение атрибутов и наборов их значений (доменов).

  5. Организация данных в виде отношений «сущность-связь».

  Прямоугольники обозначают сущности, а ромб — связь.

  

  3.Целостность данных.

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

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

  2. ограничения на разрешенные значения для каждого атрибута. Например, возраст сотрудников может быть ограничен интервалом от 18 до 65 лет.

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

  1. Целостность сущностей.

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

  2. Ссылочная целостность.

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

  3. Корпоративное ограничение целостности.

  Дополнительные правила поддержки целостности данных, определяемые пользователем или администратором.

  4.Реляционная модель данных

  Реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления, т.е. представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений. Три цели создания реляционной модели:

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

  — создание фундамента для запросов, построенных на выводах и взглядах на информацию

  — устранение проблем непротиворечивости и избыточности данных.

  Основана реляционная модель на математическом понятии – отношение, физическим представлением которого является таблица. Отношение – плоская таблица, состоящая из столбцов и строк.

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

  Степень отношения – количество атрибутов или количество столбцов в таблице.

  Кардинальность отношений – количество кортежей, или записей, или строк.

  Количество содержащихся в отношении кортежей называется кардинальностью

  отношения. И, наконец, мы подо­шли к определению самой реляционной базы данных – это набор нормализованных отношений.

  Терминология, используемая в реляционной модели, порой может привести к пу­ танице, поскольку помимо предложенных двух наборов терминов существует еще один — третий. Отношение в нем называется файлом ( file ), кортежи — записями ( records ), а атрибуты — полями ( fields ). Эта терминология основана на том факте, что физически реляционная СУБД может хранить каждое отношение в отдельном файле.

  6.Операции над данными (реляционная алгебра).

  Операции обработки кортежей.

  Эти операции связаны с изменением состава кортежей в каком-либо отношении.

  ДОБАВИТЬ — необходимо задать имя отношения и ключ кортежа. УДАЛИТЬ — необходимо указать имя отношения, а также идентифицировать кортеж или группу кортежей, подлежащих удалению. ИЗМЕНИТЬ — выполняется для названного отношения и может корректировать как один, так и несколько кортежей. Операции обработки отношений. На входе каждой такой операции используется одно или несколько отношений, результатом выполнения операции всегда является новое отношение. В реляционной алгебре определены следующие операций обработки отношений: Проекция (Вертикальное Подмножество), операция проекции представляет из себя выборку из каждого кортежа отношения значений атрибутов, входящих в список A, и удаление из полученного отношения повторяющихся строк. Выборка (Ограничение, Горизонтальное Подмножество), на входе используется одно отношение, результат — новое отношение, построенное по той же схеме, содержащее подмножество кортежей исходного отношения, удовлетворяющих условию выборки.

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

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

  Разность, операция во многом похожая на Пересечение, за исключением того, что в результирующем отношении содержатся кортежи, присутствующие в первом и отсутствующие во втором исходных отношениях. Декартово Произведение, входные отношения могут быть определены по разным схемам. Схема результирующего отношения включает все атрибуты исходных. Кроме того: степень результирующего отношения равна сумме степеней исходных отношений мощность результирующего отношения равна произведению мощностей исходных Отношений. Соединение, данная операция имеет сходство с Декартовым Произведением. Однако, здесь добавлено условие, согласно которому вместо полного произведения всех строк в результирующее отношение включаются только строки, удовлетворяющие опредленному соотношению между атрибутами соединения (А1,A2) соответствующих отношений.

  7.Проекция (Вертикальное Подмножество).

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

  

  8.Выборка (Ограничение, Горизонтальное Подмножество).

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

  9. Разность. 

  Операция во многом похожая на ПЕРЕСЕЧЕНИЕ, за исключением того, что в результирующем отношении содержатся кортежи, присутствующие в первом и отсутствующие во втором исходных отношениях.

  11.Объединение.

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

  

  13.Функциональные зависимости.

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

  Если даны два атрибута X и Y некоторого отношения, то говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X соответствует ровно одно значение Y.

  Функциональная зависимость обозначается X -> Y. Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы, составленные из нескольких атрибутов одного отношения.

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

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

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

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

  § не должны появляться ранее отсутствовавшие кортежи;

  на отношениях новой схемы должно выполняться исходное множество функциональных зависимостей.

  14.1NF — первая нормальная форма.

  Простой атрибут — атрибут, значения которого атомарны (неделимы). Сложный атрибут — получается соединением нескольких атомарных атрибутов, которые могут быть определены на одном или разных доменах. (его также называют вектор или агрегат данных). Определение первой нормальной формы: отношение находится в 1NF если значения всех его атрибутов атомарны. Пример : В базе данных отдела кадров предприятия необходимо хранить сведения о служащих, которые можно попытаться представить в отношении

  Служащий (таб_№, имя, дата_рождения, история_работы, дети). Атрибуты «история_работы» и «дети» являются сложными, и атрибут «история_работы» включает еще один сложный атрибут «история_зарплаты». Данные агрегаты выглядят следующим образом: история_работы (дата_приема, название, история_зарплаты), история_зарплаты (дата_назначения, зарплата), дети (имя, год_рождения).

  Их связь представлена на рис.

  

  

  Для приведения исходного отношения СЛУЖАЩИЙ к первой нормальной форме необходимо декомпозировать его на четыре отношения, так как это показано на следующем рисунке:

  Нормализованное множество отношений.

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

  Алгоритм нормализации описан Е.Ф.Коддом следующим образом: Начиная с отношения, находящегося на верху дерева, берется его первичный ключ, и каждое непосредственно подчиненное отношение расширяется путем вставки домена или комбинации доменов этого первичного ключа. Первичный Ключ каждого расширенного таким образом отношения состоит из Первичного Ключа, который был у этого отношения до расширения и добавленного Первичного Ключа родительского отношения.

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

  16.3NF — третья нормальная форма.

  Определение транзитивной функциональной зависимости.: Пусть X, Y, Z — три атрибута некоторого отношения. При этом X —> Y и Y —> Z, но обратное
  соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.
  Пусть имеется отношение ХРАНЕНИЕ (ФИРМА, СКЛАД, ОБЪЕМ), которое содержит информацию о фирмах, получающих товары со складов, и объемах этих складов. Ключевой атрибут — «фирма». Если каждая фирма может получать товар только с одного склада, то в данном отношении имеются следующие функциональные зависимости:

  При этом возникают аномалии:

  § если в данный момент ни одна фирма не получает товар со склада, то в базу данных нельзя ввести данные о его объеме (т.к. не определен ключевой атрибут)

  § если объем склада изменяется, необходим просмотр всего отношения и изменение кортежей для всех фирм, связанных с данным складом.

  Для устранения этих аномалий необходимо декомпозировать исходное отношение на два:

  § ХРАНЕНИЕ (ФИРМА, СКЛАД)

  § ОБЪЕМ_СКЛАДА (СКЛАД, ОБЪЕМ)

  Определение третьей нормальной формы: Отношение находится в 3НФ, если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

  18.Многозначные зависимости и четвертая нормальная форма (4NF).

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

  Многозначная зависимость является обобщением функциональной зависимости и рассматривает соответствия между множествами значений атрибутов.

  Пример в приложении 1

  Это отношение имеет значительную избыточность и его использование приводит к возникновению аномалии обновления. Например, добавление информации о том, что профессор K будет также читать лекции по курсу «Теория упругости» приводит к необходимости добавить два кортежа (по одному для каждого написанного им учебника) вместо одного. Тем не менее, отношение ПРЕПОДАВАТЕЛЬ находится в NFBC (ключевой атрибут — ИМЯ).

  Заметим, что указанные аномалии исчезают при замене отношения ПРЕПОДАВАТЕЛЬ его проекциями:

  Аномалия обновления возникает в данном случае потому, что в отношении ПРЕПОДАВАТЕЛЬ имеются:

  1. зависимость множества значений атрибута КУРС от множества значений атрибута ИМЯ

  2. зависимость множества значений атрибута УЧЕБНОЕ_ПОСОБИЕ от множества значений атрибута ИМЯ.

  Такие зависимости и называются многозначными и обозначаются как

  ИМЯ ->> КУРС ИМЯ ->> УЧЕБНОЕ_ПОСОБИЕ

  Нетрудно показать, что многозначные зависимости всегда образуют связанные пары, поэтому их часто обозначают

  ИМЯ ->> КУРС | УЧЕБНОЕ_ПОСОБИЕ

  Очевидно, что каждая функциональная зависимость является многозначной, но не каждая многозначная зависимость является функциональной.

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

  19.Целостность сущностей.

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

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

  § при добавлении записей в таблицу проверяется уникальность их первичных ключей

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

  21.Типы данных SQL.

  Символьные типы данных — содержат буквы, цифры и специальные символы.

  CHAR или CHAR(n) -символьные строки фиксированной длины. Длина строки определяется параметром n. CHAR без параметра соответсвует CHAR(1). Для хранения таких данных всегда отводится n байт вне зависимости от реальной длины строки. VARCHAR(n) — символьная строка переменной длины. Для хранения данных этого типа отводится число байт, соответствующее реальной длине строки.

  Целые типы данных — поддерживают только целые числа (дробные части и десятичные точки не допускаются). Над этими типами разрешается выполнять арифметические операции и применять к ним агрегирующие функции (определение максимального, минимального, среднего и суммарного значения столбца реляционной таблицы). INTEGER или INT— целое, для хранения которого отводится, как правило, 4 байта. (Замечание: число байт, отводимое для хранения того или иного числового типа данных зависит от используемой СУБД и аппаратной платформы, здесь приводятся наиболее «типичные» значения) Интервал значений от — 2147483647 до + 2147483648 Вещественные типы данных — описывают числа с дробной частью. FLOAT и SMALLFLOAT — числа с плавающей точкой (для хранения отводится обычно 8 и 4 байта соответсвенно). DECIMAL(p) — тип данных аналогичный FLOAT с числом значащих цифр p. DECIMAL(p,n) — аналогично предыдущему, p — общее количество десятичных цифр, n — количество цифр после десятичной запятой. Денежные типы данных — описывают, естественно, денежные величины. Если в ваша система такого типа данных не поддерживает, то используйте DECIMAL(p,n). Дата и время — используются для хранения даты, времени и их комбинаций. Большинство СУБД умеет определять интервал между двумя датами, а также уменьшать или увеличивать дату на определенное количество времени. DATE — тип данных для хранения даты. TIME — тип данных для хранения времени. INTERVAL — тип данных для хранения верменного интервала. DATETIME Двоичные типы данных — позволяют хранить данные любого объема в двоичном коде. Определения этих типов наиболее сильно различаются от системы к системе, часто используются ключевые слова: BINARY BYTE BLOB Последовательные типы данных — используются для представления возрастающих числовых последовательностей. SERIAL — тип данных на основе INTEGER, позволяющий сформировать уникальное значение.

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

  22.Операторы создания схемы базы данных.

  При описании команд предполагается, что:

  · текст, набранный строчными буквами является обязательным

  · текст, набранный прописными буквами и заключенный в угловые скобки (например, )обозначает переменную, вводимую пользователем

  · в квадратные скобки (например, [NOT NULL]) заключается необязательная часть команды

  · взаимоисключающие элементы команды разделяются вертикальной чертой (например, [UNIQUE | PRIMARY KEY]).

  Оператор создания БД: Create Database

  Оператор удаления БД: D rop D atabase

  Оператор создания таблицы: C reate T able

  [ UNIQUE | PRIMARY KEY ], …)

  Оператор удаления таблицы: D rop T able

  · NOT NULL — в этом случае элементы столбца всегда должны иметь определенное значение (не NULL)

  · один из взаимоисключающих параметров UNIQUE — значение каждого элемента столбца должно быть уникальным или PRIMARY KEY — столбец является первичным ключом.

  Оператор редактирования или модификации таблиц: добавить столбцы, удалить столбцы, редактировать столбцы

  23.Операторы управления правами доступа.

  Не каждому пользователю прикладной системы можно разрешить получать информацию из какой-либо таблицы, а тем более изменять в ней данные.

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

  · SELECT — получение информации из таблицы; UPDATE — изменение информации в таблице; INSERT — добавление записей в таблицу ; DELETE — удаление записей из таблицы; INDEX — индексирование таблицы; ALTER — изменение схемы определения таблицы; ALL — все права

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

  24.Команды модификации данных.

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

  1. Добавление:

  INSERT INTO [ (,. ) ]

   VALUES (,. )

  2. Модификация записей:

   UPDATE SET =. 

   [WHERE ]

  Если задано ключевое слово WHERE и условие, то команда UPDATE применяется только к тем записям, для которых оно выполняется. Если условие не задано, UPDATE применяется ко всем записям.

  3. Удаление записей:

  DELETE FROM имя_таблицы> [ WHERE условие> ]

  Удаляются все записи, удовлетворяющие указанному условию. Если ключевое слово WHERE и условие отсутствуют, из таблицы удаляются все записи.

  26.Вычисления внутри SELECT.

  SQL позволяет выполнять различные арифметические операции над столбцами результирующего отношения. В конструкции можно использовать константы, функции и их комбинации с арифметическими операциями и скобками. Например, чтобы узнать сколько лет прошло с 1992 года (год принятия стандарта SQL-92) до публикации той или иной книги можно выполнить команду:

  SELECT title, yearpub-1992 FROM titles WHERE yearpub > 1992;

  В арифметических вражения допускаются операции сложения (+), вычитания (-), деления (/), умножения (*), а также различные функции (COS, SIN, ABS — абсолютное значение и т.д.). Также в запрос можно добавить строковую константу :

  SELECT ‘the title of the book is’, title, yearpub-1992

  FROM titles WHERE yearpub > 1992;

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

  AVG() — среднее по всем значениям данного поля

  COUNT() или COUNT (*) — число записей

  MAX() — максимальное из всех значений данного поля

  MIN() — минимальное из всех значений данного поля

  SUM() — сумма всех значений данного поля

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

  SELECT MIN(yearpub) FROM titles;

  подсчитать количество книг в нашей базе данных:

   SELECT COUNT(*) FROM titles;

  27.Групировка данных.

  Группировка данных в операторе SELECT осуществляется с помощью ключевого слова GROUP BY и ключевого слова HAVING, с помощью которого задаются условия разбиения записей на группы.

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

  Слово HAVING работает следующим образом: сначала GROUP BY разбивает строки на группы, затем на полученные наборы накладываются условия HAVING. 

  Другой вариант использования HAVING — включить в результат только те издательтва, название которых оканчивается на подстроку «Press»:

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

  28.Cортировка данных.

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

  SELECT author FROM authors ORDER BY author;

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

  SELECT authors.author,titles.title,titles. yearpub,publishers.publisher

  WHERE titleauthors.au_id=authors.au_id AND

  ORDER BY authors.author ASC, titles.yearpub DESC;

  Ключевое слово DESC задает здесь обратный порядок сортировки по полю yearpub, ключевое слов ASC (его можно опускать) — прямой порядок сортировки по полю author.

  29.Этапы проектирования данных

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

  1. представление предметной области в том виде, как она реально существует

  2. как ее воспринимает человек (имеется в виду проектировщик базы данных)

  3. как она может быть описана с помощью символов.

  Т.е. говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.

  Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):

  

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

  Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:

  1.Концептуальное проектирование — сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:

  § обследование предметной области, изучение ее информационной структуры

  § выявление всех фрагментов, каждый из которых харакетризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами

  § моделирование и интеграция всех представлений

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

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

  Физическое проектирование — определение особенностей хранения данных, методов доступа и т.д.

  31.Блокировка

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

  Суть этого механизма в следующем: если для выполнения некоторой транзакции необходимо, чтобы некоторый объект базы данных (кортеж, набор кортежей, отношение, набор отношений. ) не изменялся непредсказуемо и без ведома этой транзакции, такой объект блокируется. Основными видами блокировок являются: блокировка со взаимным доступом, называемая также S-блокировкой (от Shared locks) и блокировкой по чтению. монопольная блокировка (без взаимного доступа), называемая также X-блокировкой от (eXclusive locks) или блокировкой по записи. Этот режим используется при операциях изменения, добавления и удаления объектов. При этом: если транзакция налагает на объект X-блокировку, то любой запрос другой транзакции с блокировкой этого объекта будет отвергнут. если транзакция налагает на объект S-блокировку, то запрос со стороны другой транзакции с X-блокировокй на этот объект будет отвергнут ; запрос со стороны другой транзакции с S-блокировокй этого объекта будет принят

  Транзакция, запросившая доступ к объекту, уже захваченному другой транзакцией в несовместимом режиме, останавливается до тех пор, пока захват этого объекта не будет снят.

  Доказано, что сериализуемость транзакций (или, иначе, их изоляция) обеспечивается при использовании двухфазного протокола блокировок (2LP — Two-Phase Locks), согласно которому все блокировки, произведенные транзакцией, снимаются только при ее завершении. Т.е выполение транзакции разбивается на две фазы: (1) — накопление блокировок, (2) — освобождение блокировок в результате фиксации или отката.

  К сожалению, применение механизма блокировки приводит к замедлению обработки транзакций, поскольку система вынуждена ожидать пока освободятся данные, захваченные конкурирующей транзакцией. Решить эту проблему можно за счет уменьшения фрагментов данных, захватываемых транзакцией. В зависимости от захватываемых объектов различают несколько уровней блокировки: блокируется вся база данных — очевидно, этот вариант неприемлим, поскольку сводит многопользовательский режим работы к однопользовательскому; блокируются отдельные таблицы ; блокируются страницы (страница — фрагмент таблицы размером обычно 2-4 Кб, единица выделения памяти для обработки данных системой) ; блокируются записи ; блокируются отдельные поля

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

  32.Архитектура «клиент-сервер».

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

  § ввод и отображение данных (взаимодействие с пользователем);

  § прикладные функции, характерные для данной предметной области;

  § функции управления ресурсами (файловой системой, базой даных и т.д.)

  Поэтому, в любом приложении выделяются следующие компоненты:

  § компонент представления данных

  § компонент управления ресурсом

  Связь между компонентами осуществляется по определенным правилам, которые называют «протокол взаимодействия».

  Компанией Gartner Group, специализирующейся в области исследования информационных технологий, предложена следующая классификация двухзвенных моделей взаимодействия клиент-сервер (двухзвенными эти модели называются потому, что три компонента приложения различным образом распределяются между двумя узлами):

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

  • простейшие прикладные функции выполняются хранимыми процедурами на сервере
  • более сложные реализуются на клиенте непосредственно в прикладной программе

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

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

  Похожие публикации:

  1. 1с как установить цену номенклатуры
  2. Как варить рис в пароварке тефаль
  3. Как установить dos на ноутбук
  4. Ниссан лиф сколько можно проехать на прочерках