- •Базы данных: основные понятия
- •Индексирование
- •Введение. Для чего нужны базы данных.
- •Компоненты субд
- •1.1.2.Обобщенные структуры или модели данных.
- •1.2.Методы доступа к данным.
- •1.2.1.Методы поиска по дереву.
- •1.2.2.Хеширование.
- •2.1.Представление данных с помощью модели "сущность-связь".
- •2.1.1.Назначение модели.
- •2.1.2.Элементы модели.
- •2.2.Диаграмма "сущность-связь".
- •Выделим интересующие нас сущности и связи:
- •Обобщая все проведенные выше рассуждения, получим диаграму "сущность-связь", показанную на слудющем рисунке.
- •2.3.Целостность данных.
- •2.4.Обзор нотаций, используемых при построении диаграмм "сущность-связь"
- •2.4.1.Нотация Чена.
- •2.4.2.Нотация Мартина
- •2.4.3.Нотация idef1x.
- •2.4.4.Нотация Баркера.
- •3.1.Иерархическая модель данных.
- •3.1.1.Структура данных.
- •3.1.2.Операции над данными, определенные в иерархической модели:
- •3.1.3.Ограничения целостности.
- •3.2.Сетевая модель данных
- •3.2.1.Структура данных.
- •3.2.2.Операции над данными.
- •3.2.3.Ограничения целостности.
- •4.1.Реляционная модель данных
- •4.1.1.Структура данных.
- •4.1.2.Свойства отношений.
- •4.2.Теория нормальных форм.
- •4.2.1.Функциональные зависимости.
- •4.2.2. 1Nf - первая нормальная форма.
- •4.2.3. 2Nf - вторая нормальная форма.
- •4.2.4. 3Nf - третья нормальная форма.
- •4.2.5. Bcnf - нормальная форма Бойса-Кодда.
- •4.2.6. Многозначные зависимости и четвертая нормальная форма (4nf).
- •4.2.7. Зависимости по соединению и пятая нормальная форма (5nf).
- •4.3.Ограничения целостности
- •4.3.1.Целостность сущностей.
- •4.3.2.Целостность ссылок
- •4.4.Операции над данными (реляционная алгебра).
- •4.4.0.Система управления базами данных leap
- •4.4.1.Операции обработки кортежей.
- •4.4.2.Операции обработки отношений.
- •4.5.Реляционное исчисление.
- •4.6.Язык sql
- •4.6.1.Типы данных sql.
- •4.6.2.Ddl: Операторы создания схемы базы данных.
- •Операторы базы данных
- •Создание и удаление таблиц
- •4.6.3.Ddl: Операторы создания индексов.
- •4.6.4.Ddl: Операторы управления правами доступа.
- •4.6.5.Dml: Команды модификации данных.
- •Удаление записей
- •4.6.6.Dml: Выборка данных.
- •4.6.7.Dml: Выборка из нескольких таблиц.
- •4.6.8.Dml: Вычисления внутри select.
- •4.6.9.Dml: Групировка данных.
- •4.6.10.Dml: Cортировка данных.
- •4.6.11.Dml: Операция объединения.
- •4.6.12.Использование представлений.
- •4.6.13.Другие возможности sql.
- •4.7.Вопросы практического програмирования.
- •4.7.1.Использование специализированных библиотек и встраиваемого sql.
- •4.7.2.Cli - интерфейс уровня вызовов.
- •4.7.3.Odbc - открытый интерфейс к базам данных на платформе ms wIndows.
- •4.7.4.Jdbc - мобильный интерфейс к базам данных на платформе Java.
- •4.8.Навигационный подход к манипулированию данными и персональные субд.
- •4.9.Транзакции, блокировки и многопользовательский доступ к данным.
- •4.10.Как определить степень соответствия субд реляционной модели.
- •5.1.Этапы проектирования данных
- •5.2.Инструментальные средства проектирования информационных систем.
- •5.3.Методологии функционального моделирования.
- •5.3.1.Диаграммы потоков данных. Нотация Йордона - Де Марко
- •5.3.2.Другие нотации, используемые при построении диаграмм потоков данных.
- •5.3.3.Методология sadt (idef0).
- •5.3.4.Сравнительный анализ методологий функционального моделирования.
- •5.4.Концептуальное моделирование. Пример построения модели "сущность-связь"
- •5.5.Правила порождения реляционных отношений из модели "сущность-связь"
- •5.5.1.Бинарные связи
- •5.5.2.N - арные связи.
- •5.5.3.Иерархические связи.
- •5.6.Проектирование реляционной базы данных на основе декомпозиции универсального отношения.
- •5.7.Обзор некоторых case-систем.
- •5.7.1.Power Designer компании Sybase.
- •5.7.2.Silverrun компании Silverrun Technologies Ltd.
- •5.7.3.BpWin и erWin компании LogicWorks.
- •5.7.4.Designer/2000 компании Oracle.
- •6.1.Ограничения реляционных баз данных.
- •6.2.Постреляционные субд.
- •6.3.Объектно-ориентированные субд.
- •6.3.1.Объектно-ориентированная парадигма.
- •6.3.2.Объектно-ориентированные субд.
- •6.3.3.Стандарт odmg.
- •6.3.4.Объектные расширения реляционных субд. Язык sql-3.
- •6.4.Объектно-реляционные субд.
- •6.5.Нечисловая обработка и ассоциативные процессоры.
- •7.1.Архитектура "клиент-сервер".
- •7.1.1.Основные понятия.
- •7.1.2.Модели взаимодействия клиент-сервер.
- •7.1.3.Мониторы транзакций.
- •Основные понятия субд
5.4.Концептуальное моделирование. Пример построения модели "сущность-связь"
Один пример построения модели "сущность-связь" был приведен в разделе 2.1, где были введены основные понятия этой модели. Здесь мы рассмотрим другой пример, связанный с проектированием базы данныхpublucations, которая использовалась для практических занятий при изучении языка SQL.
БД publicationsдолжна хранить сведения о печатных изданиях, а также ссылки на интересные ресурсы в Internet. И те и другие источники информации будут касаться одной темы, а именно "баз данных". Попробуем выделить интересующие нас сущности и определить связи между ними.
Прежде всего займемся понятием "печатное издание". Что это такое? Мы знаем, что объект "печатное издание" воплощается в виде книги, которую можно полностью описать с помощью следующих характеристик: название, автор, год издания и издатель (издательство). Можно ли на основании этого ввести сущность "книга", а названные характеристики определить в качестве ее атрибутов? Прежде чем сделать это рассмотрим более внимательно отношения между книгой и ее харакетристиками:
Один автор может написать несколько книг, и, в то же время, одна книга может быть написана несколькими авторами. Следовательно, "книга" и "автор" в данном случае выступают как различные сущности, объединяемые связью N : M. Для того, чтобы определить класс принадлежности сущностей в связи, отметим, что книг без авторов не бывает, как и авторов без книг. Значит, каждая сущность должна иметь обязательный класс принадлежности (кардинальность связи(1,N) : (1,N)).
Точно так же один издатель может издавать сразу несколько книг, но каждая конкретная книга издается только в одном месте. Следовательно, мы должны ввести сущность "издатель", ассоциируемую с "книгой" связью типа 1 : N. Т.к. каждая книга кем-то издана, класс принадлежности сущности "издатель" в данной связи будет(1,1), но в то же время мы допускаем хранение сведений об издательствах, чьих книг в нашей базе данных пока нет. Соответственно, класс принадлежности сущности "книга" в этой связи(0,N).
По поводу характеристики книги "название" можно сказать следующее: как правило авторы, пишущие на одну тему, стараются придумывать для своих призведений оригинальные названия. Поэтому, можно уверенно предположить, что каждое название обязательно связано только с одной книгой (и каждая книга имеет только одно название). Следовательно, "название" нужно оставить в списке атрибутов "книги".
Те же рассуждения можно повторить и для характеристики "год издания". Ее мы тоже оставим в списке атрибутов "книги".
Таким образом, мы определили, что у сущности "книга" имеется два атрибута "название" и "год издания". Как уже говорилось, название, скорее всего, будет однозначно определять данную книгу, чего не скажешь о годе издания. Поэтому объявим ключом сущности атрибут "название" (или "имя_книги").
Что касается всех возможных авторов, то нас интересует только одна их харакетристика - имя. Поэтому, сущность "автор" имеет только один атрибут "имя_автора", который и является ключом.
С сущностью "издатель" дел обстоит несколько сложнее. Практически все крупные издательства имеют сейчас собственные web-страницы, которые могут содержать информацию полезную для пользователей проектируемой базы данных. Поэтому, нужно рассматреть две характеристики этого объекта: "имя_издателя" и "URL" (uniform resource locator - универсальный указатель ресурсов, с помощью которого в Internet определяется путь к web - странице). Ясно, что каждый издатель имеет уникальное имя и уникальный url, но прежде чем внести их в список атрибутов, вспомним, что наша база данных должна также содержать ссылки и на другие Internet-ресурсы. Возможно, при дальнейшем анализе возникнет необходимость во введении отдельной сущности "URL". Поэтому "имя_издателя" внесем в список атрибутов сущности "издатель", а "URL" будем считать атрибутом отдельной сущности "web - страница", ассоциируемой с "издателем" связью (1,1):(1,1).
Теперь настала пора занятся объектом "ресурс Internet". Его мы можем описать с помощью понятий "имя ресурса", "url", "автор". Внимательно рассмотрев связи этих понятий с описываемым объектом, можно прийти к заключению, что "имя_ресурса" и "url" однозначно с ним связаны, т.е. являются атрибутами. В то же время, "автор" является отдельной сущностью (один ресурс может иметь много авторов, и один автор может быть создателем многих web - страниц). Т.к. мы уже ранее вввели сущность "автор" просто определим характеристики ее связи с сущностью "Internet-ресурс". Из сказанного выше следует, что эти сущности объединяются связью n : m, в то же время, автор какой-либо книги может не иметь собственной web - страницы, а авторы некоторых Internet ресурсов не указывают своих имен (т.е. можно формально сказать, что эти ресурсы не имеют авторов). Следовательно, класс принадлежности обеих сущностей будет необязательным.
Прежде чем объявить нашу модель готовой, проверим еще раз определение каждой сущности. Внимательный анализ покажет, что построенная модель имеет несколько ошибок:
Сущность "автор" имеет обязательный класс принадлежности в связи с сущностью "книга". Это означает, что мы не сможем добавить в базу данных сведения о человеке, который создал собственный web - сайт, но не написал ни одной книги. Для того, что бы устранить это ограничение изменим класс принадлежности сущности "книга" в рассматриваемой связи "автор" - "книга" на необязательный.
При анализе объекта "издатель" мы предположили, что сущность "web-страница" может быть объединена с сущностью "Internet-ресурс". Однако, мы видим, что эти сущности имеют разный набор атрибутов, следовательно выполнить такое объединение нельзя. Вспомним, что в противном случае, предполагалось единственный атрибут сущности "web - страница" присоединить к атрибутам сущности "издатель". Тем не менее, не будем этого делать, в следующем разделе мы увидим, что с помощью правил порождения реляционных отношений из модели "сущность-связь" в том и в другом случае мы получим одинаковый результат.
Готовая модель "сущность-связь" представлена на следующем рисунке: