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

  • Пример.

  • Пример

  • В этом примере АВТОР — это наименование сущности, в то время как ID, Фами­ лия, Имя и Отчество являются атрибутами сущности, которым присвоены типы

  • Как видно из рисунка, все экземпляры имеют одинаковые атрибуты, но разные данные (значения) каждого атрибута.

  • Учебник_Информатика. Стандарт третьего поколениян. В. Макарова, В. Б. Волков


    Скачать 14.49 Mb.
    НазваниеСтандарт третьего поколениян. В. Макарова, В. Б. Волков
    АнкорУчебник_Информатика.pdf
    Дата26.04.2017
    Размер14.49 Mb.
    Формат файлаpdf
    Имя файлаУчебник_Информатика.pdf
    ТипДокументы
    #5919
    страница18 из 48
    1   ...   14   15   16   17   18   19   20   21   ...   48
    Пример. В качестве примера можно привести сложное производство (или сеть
    супермаркетов), разные части которого находятся в разных городах. Каждое
    предприятие накапливает «свои» данные. Необходимо, чтобы каждое из пред­
    приятий имело доступ к одним и тем же данным, как своим, так и данным других
    предприятий. Решением данной проблемы может быть создание одной локальной
    базы данных на одном компьютере с механизмом удаленного доступа. Однако это
    решение нерационально, поскольку быстрый доступ к данным будут получать
    клиентские компьютеры только того предприятия, на котором находится СУБД.
    Другим решением данной проблемы может быть создание на каждом предпри­
    ятии своей копии СУБД. В этом случае возникает затруднение с синхронизацией
    данных между копиями (особенно в масштабах нашей страны, где в Хабаровске
    может быть разгар рабочего дня, а в Москве — глубокая ночь). Распределенная
    СУБД в этом случае обеспечивает механизм хранения данных в разных базах
    данных таким образом, что при обращении совокупность разных баз данных
    выглядит как одна база. Тогда часто используемые данные («свои» данные) на­
    ходятся в той части базы данных, которая расположена на предприятии. А при
    необходимости обратиться к «чужим» данным, СУБД делает запрос к удаленной
    СУБД и получает данные оттуда. Совокупность разных баз данных на разных
    компьютерах с точки зрения клиента выглядит как одна база данных.
    Классификация по способу доступа к БД
    Классификацию баз данных по способу доступа иллюстрирует рис. 6.5.
    Рис. 6 .5 . Классификация баз данных по способу доступа
    В мэйнфреймовых базах данных пользовательское рабочее место представляет собой текстовый или графический терминал, а вся информация обрабатывается на том же компьютере, где находится СУБД.
    В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере, а ядро СУБД находится на каждом клиентском компьютере. Доступ к данным осуществляется через локальную сеть. Синхронизация чтений и обнов­
    лений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера, а недостатком — высокая загрузка локальной сети.
    Клиент-серверные СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера. Клиент-серверные СУБД, в отличие от файл- серверных, обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Сервер является внешней по отношению к клиенту программой, и при необходимости его можно заменить другим. Недо­
    статок клиент-серверных СУБД состоит в самом факте существования сервера (что

    176
    Глава 6. Теория баз данных плохо для локальных программ — в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером.
    Встраиваемая СУБД представляет собой программную библиотеку, которая позволяет унифицированным образом хранить большие объемы данных на ло­
    кальной машине. Доступ к данным может происходить посредством запросов на языке SQL либо путем вызова функций библиотеки из приложения пользователя.
    Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют разверты­
    вания сервера.
    Классификация по скорости обработки информации
    Классификацию баз данных по скорости обработки информации иллюстрирует рис. 6.6.
    Рис. 6 .6 . Классификация баз данных по скорости обработки информации
    Операционные (operational), или рабочие (production), базы данных обладают высокими скоростями реакции на запрос, извлечения и представления информации.
    Хранилища данных и многомерные хранилища данных (data warehouse, OLAP) — это базы данных с очень большим объемом информации, подготовка представления которой занимает значительный объем времени.
    6.1.3. Функции СУБД
    Абстракция данных, управление словарем данных. Функционирование СУБД предусматривает, что определения элементов данных и их отношений (метаданные) хранятся в словаре данных (data dictionary). В свою очередь любые программы получают доступ к данным посредством СУБД. Для поиска необходимых струк­
    тур данных и их отношений СУБД использует словарь данных, помогая избежать кодирования таких сложных взаимосвязей в каждой программе. Вдобавок любые изменения, которые делаются в структуре базы данных, автоматически регистри­
    руются в словаре данных, что также освобождает программиста от необходимости модифицировать программы доступа к изменившимся структурам данных. СУБД обеспечивает абстракцию данных, тем самым устраняя в системе структурную за­
    висимость и зависимость по данным.
    Управление хранением данных. СУБД создает сложные структуры, необходимые для хранения данных, освобождая программистов от определения и программиро­
    вания физических свойств данных. Современные СУБД обеспечивают хранение

    6.1. Общие понятия
    177
    не только данных, но и связанных с данными экранных форм, схем отчетов, правил проверки данных, кода процедур, систем обработки мультимедиа, форматов изо­
    бражений, и т. п.
    Преобразование и представление данных. СУБД берет на себя задачу струк­
    турирования вводимых данных, преобразуя их в форму, удобную для хранения.
    Поэтому СУБД и в данном случае избавляет человека от рутинной работы по преобразованию логического формата данных в физический формат. Обеспечивая независимость данных, СУБД преобразует логические запросы в команды, опре­
    деляющие их физическое местоположение и извлечение. Таким образом, СУБД обеспечивает программную независимость и абстракцию данных.
    Управление безопасностью. СУБД создает систему безопасности, которая обеспечивает защиту пользователя и конфиденциальность данных внутри БД.
    Правила безопасности устанавливают, какие пользователи могут получить доступ к базе данных, к каким элементам данных пользователь может получить доступ, какие операции с данными (чтение, добавление, удаление или изменение) может выполнять пользователь.
    Управление многопользовательским доступом. СУБД создает сложные структу­
    ры, обеспечивающие доступ к данным нескольких пользователей одновременно.
    Для того чтобы обеспечить целостность и непротиворечивость данных, в СУБД применяются сложные алгоритмы, гарантирующие, что несколько пользовате­
    лей могут получить одновременный доступ к базе данных без риска нарушить ее целостность.
    Управление резервным копированием и восстановлением. В СУБД имеются процедуры резервного копирования и восстановления данных, обеспечивающие их безопасность и целостность. Современные СУБД содержат специальные утилиты, с помощью которых администраторы базы данных могут выполнять регулярные и экстренные процедуры резервного копирования и восстановления данных. Восстановление данных производится после повреждения БД, например, в случае появления сбойного сектора на жестком диске или после аварийного от­
    ключения питания. Такая возможность необходима для обеспечения целостности данных.
    Управление целостностью данных. В СУБД предусмотрены правила, обеспечи­
    вающие целостность данных, что позволяет минимизировать избыточность данных и гарантировать их непротиворечивость. Для обеспечения целостности данных используются их связи, которые хранятся в словаре данных.
    Поддержка языка доступа к данным и интерфейсов прикладного программиро­
    вания. СУБД обеспечивает доступ к данным при помощи языка запросов. Язык
    запросов — это непроцедурный язык, то есть он предоставляет пользователю воз­
    можность определить, что необходимо выполнить, не указывая, как это сделать.
    В состав языка запросов СУБД входят два основных компонента: язык определения
    данных (D ata Definition Language, DDL) и язык манипулирования данными (D ata
    Manipulation Language, DML). DDL определяет структуры, в которых размеща­
    ются данные, a DML позволяет конечным пользователям извлекать данные из

    178
    Глава 6. Теория баз данных
    БД. СУБД также предоставляет программистам доступ к данным из процедурных языков третьего поколения, таких как COBOL, С, PASCAL и др. В составе СУБД имеются административные утилиты, ориентированные на администраторов и про­
    ектировщиков базы данных и предназначенные для внедрения, текущего контроля и обслуживания базы данных.
    Интерфейсы взаимодействия с базой данных. Текущее поколение СУБД обе­
    спечивает специальные программы взаимодействия, разработанные для того, чтобы база данных могла принимать запросы конечных пользователей в сетевом окружении. Фактически, возможности взаимодействия конечных пользователей с базой данных являются неотъемлемой составляющей современных СУБД. На­
    пример, СУБД предоставляет функции взаимодействия для получения доступа к базе данных, используя в качестве внешнего интерфейса интернет-браузер
    (Mozilla Firefox, Opera или Internet Explorer). В подобной среде взаимодействие может осуществляться несколькими способами:
    □ конечный пользователь может получать ответы на запросы, заполняя экранные формы с помощью выбранного им браузера;
    □ средствами СУБД можно автоматизировать публикацию форм отчетов в Ин­
    тернете посредством веб-форматирования, что позволяет просматривать отчеты в любом браузере и др.
    6.2. Модели данных
    6.2.1. Классификация моделей данных
    Центральным понятием в области баз данных является понятие модели данных.
    Термин «модель» используется в нескольких значениях. В предыдущем разделе уже было дано определение модели данных. Другим его значением является описание на разных уровнях абстракции схемы конкретной базы данных, предназначенной для работы в определенных условиях. Несмотря на то что термины одинаковы, во втором случае подразумевается моделирование с точки зрения разработчиков информационной системы (базы данных).
    Для того чтобы спроектировать и реализовать реляционную базу данных, со­
    стоящую из трех таблиц, нет необходимости прибегать к специальным технологиям и приемам, такого рода работу можно выполнить непосредственно при помощи соответствующих SQL-выражений. Но когда речь идет о базе данных для инфор­
    мационной системы предприятия, такое «прямое» проектирование становится не только утомительным и трудоемким, но во многих случаях просто невозможным.
    Для того чтобы облегчить работу проектировщиков, в процесс проектирования включается этап моделирования данных. На этом этапе структуры данных сначала представляются в виде графических схем и диаграмм, облегчающих общее пони­

    6.2. Модели данных
    179
    мание связей и взаимодействия объектов базы данных, а также способствующих установлению большего соответствия бизнес-процессов предприятия, бизнес-пра­
    вил информационной системы и структуры данных, а затем уже реализуют базу данных в виде набора реляционных таблиц и объектов.
    На рис. 6.7 представлена классификация моделей данных в соответствии с трех­
    уровневой архитектурой, предложенной в 1975 г. Комитетом планирования стан­
    дартов и норм (Standards Planning and Requirements Committee, SPARC) Нацио­
    нального института стандартизации США (American National Standard Institute,
    ANSI), ANSI/X3/SPARC (рис. 6.8). Так, модели данных, обозначенные на рис. 6.7 как физические, соответствуют первому уровню архитектуры ANSI/X3/SPARC, да- талогические модели можно отнести ко второму, внутреннему уровню архитектуры, а мифологические модели соответствуют концептуальному уровню архитектуры, изображенной на рис. 6.8
    Рис. 6 .7. Классификация моделей данных
    Поскольку практически все современные базы данных построены на основе реляционной модели данных, для моделирования данных чаще всего применяется модель «сущность-связь», лучшим образом позволяющая моделировать схемы реляционных баз данных. Однако прежде чем рассмотреть основные принципы применения этой модели, ознакомимся с базовыми терминами и определениями, принятыми при описании структур данных.

    180
    Глава 6. Теория баз данных
    Пользователь 1
    Пользователь 2
    Пользователь
    N
    Рис. 6 .8 . Трехуровневая модель представления данных ANSI-SPARC
    6.2.2. Термины и определения
    Элемент данных определяет тип данных. Понятие элемента данных применя- ется как при концептуальном моделировании, так и в ходе создания физической модели данных. На этапе концептуального моделирования элемент данных — это элемент абстрактного типа данных, а во время создания физической модели дан­
    ных это уже элемент базового типа конкретной СУБД.
    Пример. Во время концептуального моделирования элементу данных, в кото­
    ром нужно сохранить строку, присваивается абстрактный тип String. Если эта
    концептуальная модель будет реализована на СУБД MS SQL Server, то элемент
    абстрактного типа String преобразуется к базовому типу строковых данных,
    принятому в MS SQL Server, то есть к типу varchar. При реализации этого же
    элемента на СУБД Oracle он получит тип char, являющийся базовым типом для
    строки в Oracle.
    Понятие записи в базах данных близко к этому понятию в языках программи­
    рования, но не во всем совпадает с ним.
    Схема (тип) записи определяет связную последовательность полей — позиций в структурах хранения записей. Внутренняя структура каждого поля определяется типом данных, заданным в объявлении каждой записи.

    6.2. Модели данных
    181
    Для уникальной идентификации записей одно или более полей записи должны быть объявлены явно как ключ записи. Значениями полей являются конкретные данные (числа, символьные строки, слова и пр.
    6.2.3. Модель «сущность-связь»
    Команда разработчиков анализирует требования и строит пользовательскую модель данных, или модель требований к данным. Эта модель является представ­
    лением требований пользователя к структуре и связям объектов, которые должны храниться в базе данных. Для создания пользовательской модели данных команда разработчиков задействует средства, которые называются моделью «сущность- связь» и семантической объектной моделью. Эти средства состоят из языковых и изобразительных стандартов для представления пользовательской модели данных. Их роль в разработке баз данных подобна той роли, которую исполняют алгоритмы и псевдокод в программировании.
    В этом разделе описывается и иллюстрируется использование модели «сущ-
    ностъ-связъ» (Entity-Relationship Model, MER), или ER-модели, введенной Пи­
    тером Ченом (P eter Chen) в 1976 г. Модель «сущность-связь» вошла в состав множества CASE-инструментов, которые также внесли свой вклад в ее эволюцию.
    На сегодняшний день не существует единого общепринятого стандарта для моде­
    ли «сущность-связь», но есть набор общих конструкций, которые лежат в основе большинства вариантов этой модели. Символы, применяемые для графического представления модели «сущность-связь», весьма различны.
    Термины модели «сущность-связь»
    Поскольку термином сущность обозначают класс объектов, можно также встре­
    тить определение класса сущностей, которое является синонимичным термину сущность. Сущность определяет собой некоторый тип сложной структуры данных, то есть наличие определенных полей (атрибутов), их имена и элементарные типы данных, к которым они принадлежат.
    Пример. Пример структурно-графического определения класса АВТОР изо­
    бражен на рис. 6.9.
    АВТОР
    ID
    int
    Фамилия string
    Имя string
    Отчество string
    Рис. 6 .9 . Определение класса сущностей АВТОР

    182
    Глава 6. Теория баз данных
    В этом примере АВТОР — это наименование сущности, в то время как ID, Фами­
    лия, Имя и Отчество являются атрибутами сущности, которым присвоены типы,
    соответствующие хранимым данным.
    Пример. Класс сущностей АВТОР описывается атрибутами ID, Фамилия, Имя,
    Отчество.
    В модели «сущность-связь» предполагается, что все экземпляры данного класса сущностей имеют одинаковые атрибуты.
    В экземпляре сущности, в отличие от класса, каждый атрибут содержит данные, характеризующие конкретный объект.
    Пример. Пример нескольких экземпляров сущности класса АВТОР приведен
    на рис. 6.10.
    1
    Пушкин
    Александр
    Сергеевич
    2
    Гоголь
    Николай
    Васильевич
    22
    Чехов
    Антон
    Павлович
    Рис. 6 .1 0 . Несколько экземпляров сущностей класса АВТОР
    Как видно из рисунка, все экземпляры имеют одинаковые атрибуты, но разные
    данные (значения) каждого атрибута.
    Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности. Идентификатор может быть уникальным (unique) либо неуникальным
    (nonunique). Если идентификатор является уникальным, его значение будет указы­
    вать на один и только на один экземпляр сущности. Если идентификатор является неуникальным, его значение будет указывать на некоторое множество экземпляров.
    Синонимом термину «идентификатор» является термин «ключ».
    Пример. В классе сущностей АВТОР идентификатором является атрибут ID.
    В случае, если мы в качестве идентификатора приняли бы атрибут Фамилия,
    этот идентификатор был бы неуникальным. Например, он указывал бы на группу
    сущностей со значением Толстой у данного атрибута.

    6.2. Модели данных
    183
    Модель «сущность-связь» включает в себя классы связей и экземпляры связей.
    Классы связей определяют взаимоотношения между классами сущностей, а экзем­
    пляры связи — взаимоотношения между экземплярами сущностей. У связей могут быть атрибуты.
    Класс связей может затрагивать несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи (relationship degree).
    Изображенная на рис. 6.11 связь ПРОДАВЕЦ-ЗАКАЗ имеет степень 2, поскольку в ней участвуют два класса сущностей: ПРОДАВЕЦ и ЗАКАЗ. Связь РО ДИ ТЕЛЬ имеет степень 3, так как в ней участвуют три класса сущностей: МАТЬ, О ТЕЦ и РЕБЕНОК. Связи степени 2 весьма распространены, их часто называют еще
    бинарными связями (binary relationships).
    Рис. 6 .1 1 . Типы связей
    Типы бинарных связей
    На рис. 6.12 показаны три типа бинарных связей.
    В связи 1:1 (один к одному) одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. Связь С Л У Ж ЕБН Ы Й -А В -
    ТОМОБИЛЬ связывает одиночную сущность класса СО ТРУ ДН ИК с одиночной сущностью класса АВТОМОБИЛЬ. В соответствии с этой диаграммой, ни за одним сотрудником не закреплено более одного автомобиля и ни один автомобиль не за­
    креплен более чем за одним сотрудником.
    СОТРУДНИК
    АВТОМОБИЛЬ
    СЛУЖЕБНЫЙ-АВТОМОБИЛЬ
    ОБЩЕЖИТИЕ-СТУДЕНТ
    СТУДЕНТ
    --------- ---------
    КЛУБ
    СТУДЕНТ-КЛУБ
    Рис. 6 .1 2 . Три типа бинарных связей

    184
    Глава 6. Теория баз данных
    В связи типа UN (один к N, или один ко многим) экземпляр сущности одного типа связан со многими экземплярами сущности другого типа. В нашем примере таким типом связи является связь О БЩ ЕЖ И ТИЕ-СТУДЕНТ, где единичный экземпляр сущности класса ОБЩ ЕЖ И ТИЕ связан со многими экземплярами сущ­
    ности класса СТУДЕНТ, то есть в общежитии может проживать много студентов, но каждый студент живет только в одном общежитии.
    Позиции, в которой стоят символы 1 и N, имеют значение. Единица стоит на той стороне связи, где располагается ОБЩ ЕЖ И ТИ Е, a N — на той, где располагается
    СТУДЕНТ. Если бы символы 1 и N располагались наоборот (ЛГ:1), получилось бы, что в общежитии живет один студент, причем каждый студент живет в нескольких общежитиях. Это, разумеется, не так.
    Третьем типом бинарной связи является связь N\M (читается N к М, или многие
    ко многим). В нашем примере это связь СТУДЕНТ-КЛУБ, связывающая экземпля­
    ры сущностей класса СТУДЕНТ с экземплярами сущностей класса КЛУБ. Один студент может быть членом нескольких клубов, а в одном клубе может состоять много студентов.
    Числа внутри ромба, символизирующего связь, обозначают максимальное количество сущностей на каждой стороне связи. Эти ограничения называются
    максимальными кардинальными числами, а совокупность из двух таких ограничений для обеих сторон связи называется максимальной кардинальностью связи.
    Преимущества ER-моделирования
    Исключительная концептуальная простота. ER-модель дает очень простое и наглядное представление об основных логических объектах БД и существующих между ними связях, поэтому использование такой модели значительно упрощает разработку и организацию сложных баз данных.
    Наглядное представление. ER-модель дает проектировщикам баз данных, про­
    граммистам и конечным пользователям простое наглядное представление о данных и связях между ними. Поэтому ER-модель является чрезвычайно эффективным средством, интегрирующим различные представления о данных в единую рабочую среду.
    Хорошая интеграция с реляционной моделью данных. ER-модель хорошо инте­
    грируется с реляционной моделью БД. Такая интеграция помогает эффективно структурировать процесс проектирования реляционных БД.
    Недостатки ER-моделирования
    Недостаточные возможности представления ограничений. С помощью ER-mo- дели легко изобразить ограничения, имеющие непосредственное отношение к связ­
    ности. Например, ограничение «автор может работать над несколькими книгами, или более чем над одной книгой, но не более чем над тремя книгами» легко изобра­
    жаются средствами ER-модели. Однако некоторые ограничения, например, «оплата автору может варьироваться в диапазоне от 4 до 25 %» или «автор не имеет права работать больше 10 часов подряд», в ER-модели представить невозможно, и они должны обрабатываться на уровне приложений.

    6.3. Реляционные базы данных
    185
    Ограниченные возможности представления отношений. Связи представляются как нечто, происходящее между сущностями. Поэтому связи между атрибутами внутри сущностей не могут быть представлены средствами ER-модели.
    Отсутствие языка манипулирования данными. Сторонники реляционной мо­
    дели обычно указывают на отсутствие команд манипулирования данными в ER- модели. Отсутствие таких команд делает ER-модель «неполной».
    Утеря информационного наполнения. ER-модель сильно «переполнится», если в ней отобразить все ее атрибуты. Поэтому проектировщики баз данных обычно избегают полного отображения атрибутов, таким образом, сужая информационное наполнение ER-модели.
    ВНИМАНИЕ---------------------------------------------------------------------------------------------------------------
    1   ...   14   15   16   17   18   19   20   21   ...   48


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