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

Подождите немного. Документ загружается.

Уфимский государственный авиационный технический

университет

Кафедра ТК

Реферат

Тема: «Проблемы проектирования базы данных: концептуальная,

логическая и физическая модели».

Выполнил студент гр. РС – 313

Голенастов И.В.

Проверил:

УФА-2004г.

Содержание

Введение 3

1 Объект исследования как система 3

1.1 Система баз данных 3

1.2 Структура системы баз данных 6

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

1.2.2 Концептуальный уровень 10

1.2.3 Внутренний уровень 11

1.3 Избыточное дублирование данных и аномалии 12

1.4 Базы данных в Internet и intranet 15

2 Общие системные принципы 18

2.1 Принцип декомпозиции 18

2.2 Принцип оперативного принятия решения 18

2.3 Принцип согласованности 19

2.4 Принцип совместимости (достижимости) 19

2.5 Принцип реализуемости 19

2.6 Принцип типизации и стандартизации 19

2.7 Принцип самоорганизации (гибкости) 19

3 Проблемы управления базой данных 20

4 Модели 20

4.1. Иерархическая модель 20

4.2. Сетевая модель 21

4.3. Реляционная модель 22

4.4. Постреляционная модель 22

4.5. Многомерная модель 23

4.6. Объектно-ориентированная модель 24

Заключение 25

Список использованной литературы 27

Введение

Проектирование информационных систем, включающих в себя базы данных,

осуществляется на физическом и логическом уровнях. Решение проблем

проектирования на физическом уровне во многом зависит от используемой СУБД,

зачастую автоматизировано и скрыто от пользователя. В ряде случаев

пользователю предоставляется возможность настройки отдельных параметров

системы, которая не составляет большой проблемы.

Логическое проектирование заключается в определении числа и структуры

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

разработке алгоритмов обработки информации, создании форм для ввода и

редактирования данных в базе и решении ряда других задач.

Решение задач логического проектирования БД в основном определяется

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

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

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

можно выделить три основных подхода:

1. Сбор информации об объектах решаемой задачи в рамках одной таблицы

(одного отношения) и последующая декомпозиция ее на несколько

взаимосвязанных таблиц на основе процедуры нормализации отношений.

2. Формулирование знаний о системе (определение типов исходных данных и

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

систе-мы (системы автоматизации проектирования и разработки баз данных)

готовой схемы БД или даже готовой прикладной информационной системы.

3. Структурирование информации для использования в информационной

системе в процессе проведения системного анализа на основе совокупности

правил и рекомендаций.

1 Объект исследования как система

1.1 Система баз данных

Базы данных— это компьютеризированная система хранения записей, т.е.

компьютеризированная система, основное назначение которой — хранить

информацию, предоставляя пользователям средства ее извлечения и модифика-

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

пользователя или организации, использующей систему, иначе говоря, все

необходимое для текущей работы данного пользователя или предприятия.

На рис. 1 показана весьма упрошенная схема системы баз данных. Здесь

отражено четыре главных компонента системы, а именно: данные, аппаратное

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

компонентов кратко рассматривается ниже.

Рис. 1 Упрощенная схема системы баз данных

Данные

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

и на крупнейших мэйнфреймах. Нет необходимости говорить, что

предоставляемые каждой конкретной системой средства в некоторой мере зависят

от мощности и возможностей базовой машины. В частности, системы на больших

машинах ("большие системы"), в основном, многопользовательские, тогда как

системы на малых машинах ("малые системы"), как правило,

однопользовательские. Однопользовательская система (single-user system) — это

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

одного пользователя, а многопользовательская система (multi-user system) — это

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

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

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

пользователей, между этими системами фактически не существует большого

различия. Основная задача большинства многопользовательских систем—

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

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

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

конечному пользователю (о чем речь пойдет ниже).

Аппаратное обеспечение

К аппаратному обеспечению системы относится следующее.

• Тома вторичной (внешней) памяти (обычно это магнитные диски),

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

ввода-вывода (дисководы и т.п.), контроллеры устройств, каналы ввода-вывода и

т.д.

• Аппаратный процессор (или процессоры) вместе с основной (первичной)

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

системы баз данных.

Программное обеспечение

Между собственно физической базой данных (т.е. данными, которые реально

хранятся) и пользователями системы располагается уровень программного

обеспечения, который можно называть по-разному: менеджер базы данных

(database manager), сервер базы данных (database server) или, что более

привычно, система управления базами данных, СУБД (database management

system — DBMS). Все запросы пользователей на доступ к базе данных

обрабатываются СУБД. Все имеющиеся средства добавления файлов (или

таблиц), выборки и обновления данных в этих файлах или таблицах также

предоставляет СУБД. Основная задача СУБД — предоставить пользователю базы

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

обеспечения. (Пользователь СУБД более отстранен от этих деталей, чем при-

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

Иными словами, СУБД позволяет конечному пользователю рассматривать базу

данных как объект более высокого уровня по сравнению с аппаратным

обеспечением, а также предоставляет в его распоряжение набор операций,

выражаемых в терминах языка высокого уровня (например, набор операций,

которые можно выполнять с помощью языка SQL).

Пользователи

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

группы.

• Первая группа — прикладные программисты, которые отвечают за

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

применимы такие языки, как COBOL, PL/I, C++, Java или какой-нибудь

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

доступ к базе данных посредством выдачи соответствующего запроса к СУБД

(обычно это некоторый SQL-оператор).

• Вторая группа — конечные пользователи, которые работают с системой

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

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

интерактивных приложений, упомянутых выше, или же интерфейс,

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

подобный интерфейс также поддерживается интерактивными приложениями,

однако эти приложения не создаются пользователями-программистами, а

являются встроенными в СУБД. Большинство СУБД включает по крайней мере

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

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

(их часто иначе называют операторами (statement) или командами (commands)),

например SELECT или INSERT. Язык SQL — типичный пример языка запросов

базы данных.

• Третья группа — администраторы базы данных.

1.2 Структура системы баз данных

Структурой системы называется её расчленение на группы элементов с

указанием связей между ними, неизменное на всё время рассмотрения и дающее

представление о системе в целом. Иначе можно сказать, что структура это

множество элементов и связей между ними, принадлежащее определённому

уровню декомпозиции. Важнейшим стимулом и сутью декомпозиции является

упрощение системы, слишком сложной для рассмотрения целиком.

Архитектура ANSI/SPARC включает три уровня: внутренний, внешний и

концептуальный (рис. 2). В общих чертах они представляют собой следующее.

• Внутренний уровень (также называемый физическим) наиболее близок к

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

информации на физических устройствах.

• Внешний уровень (также называемый пользовательским логическим)

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

для отдельных пользователей.

• Концептуальный уровень (также называемый общим логическим или

просто логическим) является "промежуточным" уровнем между двумя первыми.

Рис. 2 Три уровня архитектуры ANSI/SPARC

Если внешний уровень связан с индивидуальными представлениями

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

пользователей. Иначе говоря, может существовать несколько внешних

представлений, каждое из которых состоит из более или менее абстрактного

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

представление, состоящее из абстрактного представления базы данных в целом.

(Вспомните, что большинство пользователей интересует не вся база данных, а

лишь ее некоторая ограниченная часть.) Также существует единственное

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

данных

Для лучшего понимания этих идей рассмотрим пример, представленный на

рис. 3. Здесь отображено концептуальное представление простой базы данных о

персонале, а также соответствующие ему внутреннее и два внешних

представления (одно — для пользователя, применяющего язык PL/I, а другое —

для пользователя, применяющего язык COBOL). Конечно, этот пример полностью

гипотетичен и мало похож на реальные системы, поскольку в нем умышленно

опущены многие не относящиеся к делу детали.

Рис. 3 Пример трех уровней представления базы данных

Рассматриваемый здесь пример нуждается в пояснениях.

 На концептуальном уровне база данных содержит информацию о типе

сущности с именем EMPLOYEE (служащий). Каждый экземпляр

сущности EMPLOYEE включает атрибуты номера служащего

EMPLOYEE_NUMBER (длиной шесть символов), номера отдела

DEPARTMENT_NUMBER (длиной четыре символа) и зарплаты

служащего SALARY (пять десятичных цифр).

 На внутреннем уровне служащие представлены типом хранимой

записи STORED_EMP, длина которой составляет 20 байт. Запись

STORED_EMP содержит четыре хранимых поля: шестибайтовый префикс

(возможно, содержащий управляющую информацию, такую как флаги или

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

сущности, которая представляет служащего. Кроме того, записи STORED

ЕМР индексированы по полю ЕМР# с помощью индекса ЕМРХ

определение которого не показано.

 Пользователь, применяющий язык PL/I, имеет дело с соответствующим

внешним представлением базы данных. В нем каждый сотрудник

представлен записью на языке PL/I, содержащей два поля (номера отделов

не представляют интереса для данного пользователя, поэтому в

представлении они опущены). Тип записи определен с помощью обычной

структуры, соответствующей правилам языка PL/I.

 Аналогично пользователь, применяющий язык COBOL, имеет дело с

собственным внешним представлением базы данных, в котором каждый

сотрудник представлен записью на языке COBOL, содержащей, опять же,

два поля (в данном случае опущен размер оклада). Тип записи определен с

помощью обычного описания на языке COBOL в соответствии с

принятыми в нем стандартными правилами.

Нужно обратить внимание, что в каждом случае соответствующие элементы

данных могут меть различные имена. Например, к номеру сотрудника

обращаются, как к полю EMPt в представлении для языка PL/I и как к полю

EMPNO в представлении для языка COBOL. Этот же атрибут в концептуальном

представлении имеет имя EMPLOYEE_NUMBER, а во внутреннем представлении

— имя ЕМР#. Конечно, системе должны быть известны все эти соответствия.

Например, она должна знать, что поле EMPNO в представлении для языка

COBOL образовано из концептуального поля EMPLOYEE NUMBER, которое, в

свою очередь, отвечает хранимому полю ЕМР# во внутреннем представлении.

Такие соответствия, или отображения, явно не показаны на рис. 3.

В данном случае не имеет особого значения, является ли рассматриваемая

система реляционной или какой-нибудь иной.

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

Внешний уровень — это индивидуальный уровень пользователя. Как было

сказано главе 1, пользователь может быть прикладным программистом или

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

(Особое место среди пользователей занимает администратор базы данных (АБД).

В отличие от остальных пользователей, АБД интересует также концептуальный и

внутренний уровни. Об этом еще будет говориться в следующих двух разделах.)

У каждого пользователя есть свой язык общения.

 Для прикладного программиста это либо один из распространенных

языков программирования (например, PL/I, C++ или Java), либо

специальный язык рассматриваемой системы. Такие оригинальные языки

называют языками четвертого поколения на том (не вполне

определенном!) основании, что машинный код, язык ассемблера и такие

языки, как PL/I, можно считать языками трех первых "поколений", а

оригинальные языки модернизированы по сравнению с языкам третьего

поколения так же, как языки третьего поколения улучшены по сравнению

с языком ассемблера.

 Для конечного пользователя это или специальный язык запросов, или язык

специального назначения, который может быть основан на использовании

форм и меню, разработан специально с учетом требований пользователя и

интерактивно поддерживаться некоторым оперативным приложением.

Для нашего обсуждения важно, что все эти языки включают подъязык

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

объектами баз данных и операциями с ними. Иначе говоря, подъязык данных

встроен в базовый язык, который дополнительно обеспечивает различные не

связанные с базами данных возможности (такие, как локальные (временные)

переменные, вычислительные операции, логические операции и т.д.). Система

может поддерживать любое количество базовых языков и любое количество

подъязыков данных. Однако существует один язык, который поддерживается

практически всеми сегодняшними системами. Это язык SQL. Большинство систем

позволяет использовать язык SQL и интерактивно, как самостоятельный язык

запросов, и посредством внедрения его операторов в другие языки

программирования, такие как PL/I и Java.

Хотя с точки зрения архитектуры удобно различать подъязык данных и

включающий его базовый язык, на практике они могут быть неразличимы

настолько, насколько это имеет отношение к пользователю. Безусловно, с точки

зрения пользователя предпочтительнее, чтобы они были неразличимы. Если они

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

ясно и легко различаются, говорят, что эти языки слабо связаны. В то время как

некоторые коммерческие. системы (особенно объектные системы) поддерживают

сильную связь, большинство систем, в частности системы SQL, обычно

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

предоставить пользователю более унифицированный набор возможностей, но,

очевидно, они требуют больше усилий со стороны системных проектировщиков и

разработчиков, которые, вероятно, рассчитывают на сохранение статус-кво.

В принципе, любой подъязык данных является на самом деле комбинацией

по крайней мере двух подчиненных языков — языка определения данных (data

definition language — DDL), который поддерживает определения или объявления

объектов базы данных, и языка обработки данных (data manipulation language —

DML), который поддерживает операции с такими объектами или их обработку.

Например, рассмотрим пользователя языка PL/I (см. рис. 3). Подъязык данных

этого пользователя включает определенные средства языка PL/I, применяемые

для организации взаимодействия с СУБД.

 Язык определения данных включает некоторые описательные структуры

языка PL/I, необходимые для объявления объектов базы данных. Это сам

оператор DECLARE (DCL), определенные типы данных языка PL/I, а также

возможные специальные дополнения для языка PL/I, предназначенные для

поддержки новых объектов, которые не поддерживаются существующей

версией языка PL/I.



Язык обработки данных состоит из тех выполняемых операторов языка PL/

I, которые передают информацию в базу данных и из нее; опять же,

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

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

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

чем-то абстрактным по сравнению с выбранным способом физического хранения

данных. В соответствии с терминологией ANSI/SPARC представление отдельного

пользователя называется внешним представлением. Таким образом, внешнее

представление— это содержимое базы данных, каким его видит определенный

пользователь (т.е. для каждого пользователя знешнее представление и есть та

база данных, с которой он работает). Например, пользователь из отдела кадров

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

плюс набор записей с информацией о служащих и ничего не знать о записях с

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

в отделе снабжения.

В общем случае внешнее представление состоит из некоторого множества

экземпляров каждого из многих типов внешних записей (которые вовсе не

обязательно должны совпадать с хранимыми записями). Предоставляемый в

распоряжение пользователя подъязык данных всегда определяется в терминах

внешних записей. Например, операция выборки языка обработки данных

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

Каждое внешнее представление определяется посредством внешней схемы,

которая, в основном, состоит из определений записей каждого из типов, присутст-

вующих в этом внешнем представлении (см. рис. 3). Внешняя схема записывается

с помощью языка определения данных, являющегося подмножеством подъязыка

данных пользователя. (Поэтому язык определения данных иногда называют

внешним языком определения данных.) Например, тип внешней записи о работни-

ке можно определить как шестисимвольное поле с номером работника, плюс поле

из пяти десятичных цифр, предназначенное для его зарплаты, и т.д. Кроме того,

может потребоваться определить отображение между внешней и исходной

концептуальной схемами.

Рис. 4 Детальная схема архитектуры системы баз данных

1.2.2 Концептуальный уровень

Концептуальное представление — это представление всей информации

базы данных в несколько более абстрактной форме (как и в случае внешнего

представления по сравнению с физическим способом хранения данных. Однако

концептуальное представление существенно отличается от представления данных

каким-либо отдельным пользователем. Вообще говоря, концептуальное

представление — это представление данных такими, какими они являются на

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

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

Концептуальное представление состоит из некоторого множества

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

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

информацию об отделах, набора экземпляров записей, содержащих информацию