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

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

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

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

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

Отношение называется нормализованным или приведенным к первой нормальной форме (1НФ), если все его атрибуты простые или атомарные (далее – неделимые). Отношение, находящееся в первой нормальной форме, будет иметь следующие свойства:

■ в отношении нет одинаковых кортежей;

■ кортежи не упорядочены;

■ атрибуты не упорядочены и различаются по наименованиям;

■ все значения атрибутов атомарные.

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

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

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

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

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

На практике эти зависимости отражают взаимосвязи, обнаруженные между объектами предметной области, и являются дополнительными ограничениями, определяемыми предметной областью. Таким образом, функциональная зависимость – семантическое понятие. Она возникает, когда по значениям одних данных в предметной области можно определить значения других данных. Например, зная табельный номер сотрудника, можно определить его фамилию. Функциональная зависимость задает дополнительные ограничения на данные, которые могут храниться в отношениях. Для корректности БД необходимо при выполнении операций модификации базы проверять все ограничения, определенные функциональными зависимостями.

Функциональная зависимость атрибутов отношения напоминает понятие зависимости в математике. Функциональная зависимость в математике – это тройка объектов X, Y и f , где Х множество, представляющее область определения функции, Y – множество значений, а f – правило, согласно которому каждому элементу ставится в соответствие один и только один элемент В противоположность этому в отношениях значение зависимого атрибута может принимать различные непредсказуемые значения в различных состояниях БД, соответствующих различным состояниям предметной области. Например, изменение сотрудником фамилии при вступлении в законный брак приведет к тому, что при том же значении детерминанта, скажем табельного номера, значение зависимого аргумента будет другим.

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

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

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

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

Отношение находится в третьей нормальной форме (ЗНФ), если оно находится в 2НФ и все неключевые атрибуты взаимно независимы.

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

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

Алгоритм разработки включает в себя три этапа.

Этап I. Приведение к 1НФ. Здесь необходимо определить и задать отношения, отображающие понятия предметной области. Все отношения автоматически находятся в 1НФ.

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

. Ключ– сложный ключ.

– зависимость всех атрибутов от ключа отношения;

– зависимость некоторых атрибутов от части сложного ключа.

– оставшаяся часть исходного отношения;

– новое отношение.

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

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

Пусть, например, исходное отношение –. К – ключ.

Тогда функциональные зависимости имеют следующий вид:

После декомпозиции отношения получим:

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

1.1 Логические модели

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

Пример. Возьмем утверждение: "Инфляция в стране превышает прошлогодний уровень в 2 раза". Это можно записать в виде логической модели: r(InfNew, InfOld, n), где r(x,y) - отношение вида "x=ny", InfNew - текущая инфляция в стране, InfOld - инфляция в прошлом году. Тогда можно рассматривать истинные и ложные предикаты, например, r(InfNew, InfOld, 2)=1, r(InfNew, InfOld, 3)=0 и т.д. Очень полезные операции для логических выводов - операции импликации, эквиваленции.

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

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

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

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

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

1.2 Продукционные модели

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

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

Взаимосвязанный набор продукций образует систему. Основная проблема вывода знания в системе продукций является выбор для анализа очередной продукции. Конкурирующие продукции образуют фронт.

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

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

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

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

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

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

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

Аннотация

В данной курсовой работе описывается проектирование базы данных центральной городской больницы и ее реализация в Oracle Datebase. Была представлена предметная область, разработаны концептуальная, логическая и физическая модели данных. Средствами Oracle Datebase созданы необходимые таблицы, запросы, отчеты. Курсовая работа состоит из.

Введение 3

1.Предметная область 4

2.Концептуальная модель 5

3.Логическая модель базы данных 7

4.Модель физической организации данных 9

5.Реализация баз данных в Oracle 9

6.Создание таблиц 10

7.Создание запросов 16

8.Заключение 27

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

Введение

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

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

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

Предметная область

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

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

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

Концептуальная модель

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

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

Самой популярной моделью концептуального проектирования является модель «сущность-связь» (ER-модель), она относится к семантическим моделям.

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

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

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

Атрибут – характеристика (параметр) не которой сущности.

Домен – множество значений (область определения атрибутов).

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

Набор сущностей для центральной больницы (в скобках указаны атрибуты сущностей, подчёркнуты ключевые атрибуты):

ПАЦИЕНТЫ (Код пациента , фамилия, имя, дата рождения, номер страхового полиса, код отделения);

ЛЕЧЕНИЕ (Код больного , диагноз, дата выписки, код врача, стоимость);

ОТДЕЛЕНИЯ(Код отделения , название отделения, количество палат);

ПОСТУПЛЕНИЯ (Код больного, дата поступления, код палаты);

ПАЛАТЫ (Код палаты , кол-во мест, код отделения);

ВРАЧИ (Код врача, фамилия, имя, дата рождения, номер личного дела, код отделения);

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

Логическая модель базы данных

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

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

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

Атрибут (поле) – любой столбец в таблице.

Кортежи (записи) – строки таблицы.

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

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

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

Рис.2.
4. Модель физической организации данных

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

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-26

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

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

Основными компонентами логической модели являются:

Сущности;

Атрибуты сущности;

Связи между сущностями.

Сущность.

Сущность моделирует структуру однотипных информационных объектов (документов, хранилищ данных, таблиц базы данных). В пределах модели данных сущность имеет уникальное имя, выраженное существительным. Например: студент, счет-фактура, справочник_товаров.

Сущность является шаблоном на основании которого создаются конкретные экземпляры сущности. Например: экземпляр сущности студент – Иванов Иван Иванович.

Сущность обладает следующими свойствами:

Каждая сущность имеет уникальное имя, и к одному и тому же имени должна применятся одинаковая интерпретация;

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

Сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности;

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

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

Рис. 40 Сущность модели данных.

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

Зависимая сущность изображается прямоугольником со скругленными углами рис. (сущность льгота зависимая от сущности житель_бийска)

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

Атрибут может быть либо обязательным, либо необязательным (рисунок 2.23). Обязательность означает, что атрибут не может принимать неопределенных значений (null values). Атрибут может быть либо описательным (т.е. обычным дескриптором сущности), либо входить в состав уникального идентификатора (первичного ключа).

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

Атрибуты входящие в состав ключа должны быть обязательными и не изменятся во времени. Атрибуты входящие в состав ключа должны быть обязательными и не изменятся в времени. Например: имеем сущность Житель_Бийска.

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

Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь - это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя.

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

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

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

• продавец может получить вознаграждение за 1 или более контрактов;
• контракт должен быть инициирован ровно одним продавцом.

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

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

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

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

Рис. 43

Неидентифицирующая изображается штриховой линией.

Рис.44.

При идентифицирующей связи ключ родительской сущности переносится в область ключа зависимой сущности с указанием в скобках (FK)- внешний ключ. При неидентифицирующей связи ключ родительской сущности переносится в область атрибутов дочерней сущности с указанием в скобках (FK)- внешний.

Рис. 45 Идентифицирующая связь.

Рис. 46 Неидентифицирующая связь.

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

Рис. 47 Связь многие ко многим.

В процессе моделирования данных, могут быть выявлены сущности часть атрибутов и связей которых одинаковы. Для моделирования таких случаев используется иерархия категорий. Все общие атрибуты выделяются в сущность называемую супертипом. Оставшиеся атрибуты помещаются в сущности называемые подтипоми. И они связываются с супертипом связью называемой ДИСКРИМИНАНТ.

Например:

Рис. 48 Пример иерархии категорий.

Понятия БД и СУБД.

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

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

Система управления базами данных (СУБД) - это комплекс языко­вых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по используемой модели данных. Так, СУБД, осно­ванные на использовании реляционной модели данных, называют ре­ляционными СУБД.

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

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

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

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

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

Выделяют следующие виды СУБД:

* полнофункциональные СУБД;

* серверы БД;

* средства разработки программ работы с БД.

По характеру использования СУБД делят на многопользователь­ские (промышленные) и локальные (персональные).

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

* возможность организации совместной параллельной работы мно­гих пользователей;

* масштабируемость;

* переносимость на различные аппаратные и программные платформы;

* устойчивость по отношению к сбоям различного рода, в том чис­ле наличие многоуровневой системы резервирования хранимой информации;

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

Персональные СУБД - это программное обеспечение, ориентиро­ванное на решение задач локального пользователя или небольшой группы пользователей и предназначенное для использования на пер­сональном компьютере. Это объясняет и их второе название - на­стольные. Определяющими характеристиками настольных систем яв­ляются:

* относительная простота эксплуатации, позволяющая создавать на их основе работоспособные пользовательские приложения;

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

По используемой модели данных СУБД разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и др. Некоторые СУБД могут одновременно поддерживать несколько моделей данных.

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

* язык описания данных - высокоуровневый непроцедурный язык
декларативного типа, предназначенный для описания логической
структуры данных;

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

Названные языки в различных СУБД могут иметь отличия. Наи­большее распространение получили два стандартизованных языка: QBE - язык запросов по образцу и SQL - структурированный язык запросов. QBE в основном обладает свойствами языка манипулирования данными, SQL сочетает в себе свойства языков обоих типов.

СУБД реализует следующие основные функции низкого уровня:

* управление данными во внешней памяти;

* управление буферами оперативной памяти;

* управление транзакциями;

* ведение журнала изменений в БД;

* обеспечение целостности и безопасности БД.

Реализация функции управления данными во внешней памяти обес­печивает организацию управления ресурсами в файловой системе ОС.

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

Механизм транзакций используется в СУБД для поддержания це­лостности данных в базе. Транзакцией называется некоторая недели­мая последовательность операций над данными БД, которая отсле­живается СУБД от начала и до завершения. Если по каким-либо причинам (сбои и отказы оборудования, ошибки в программном обес­печении, включая приложение) транзакция остается незавершенной, то она отменяется.

Транзакции присущи три основных свойства:

* атомарность (выполняются все входящие в транзакцию операции или ни одна);

* сериализуемость (отсутствует взаимное влияние выполняемых в одно и то же время транзакций);

* долговечность (даже крах системы не приводит к утрате резуль­татов зафиксированной транзакции).

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

Ведение журнала изменений выполняется СУБД для обеспечения надежности хранения данных в базе при наличии аппаратных и про­граммных сбоев.

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

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

Этапы создания БД.

Проектирование баз данных информационных систем является до­статочно трудоемкой задачей. Оно осуществляется на основе форма­лизации структуры и процессов предметной области, сведения о которой предполагается хранить в БД. Различают концептуальное и схемно-структурное проектирование.

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

Перечислим этапы концептуального проектирования:

1. Изучение предметной области для формирования общего пред­ставления о ней;

2. Выделение и анализ функций и задач разрабатываемой ИС;

3. Определение основных объектов-сущностей предметной области
и отношений между ними;

4. Формализованное представление предметной области.

При проектировании схемы реляционной БД можно выделить сле­дующие процедуры:

1.Определение перечня таблиц и связей между ними;

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

3.Установление индексирования для полей в таблицах;

4.Разработка списков (словарей) для полей с перечислительными
данными;

5.Установление ограничений целостности для таблиц и связей;

6.Нормализация таблиц, корректировка перечня таблиц и связей.

Реляционные БД.

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

Строки таблицы называются записями. Все записи таблицы имеют одинаковую структуру - они состоят из полей (элементов данных), в которых хранятся атрибуты объекта (рис. 1). Каждое поле записи содержит одну характеристику объекта и представляет собой заданный тип данных (например, текстовая строка, число, дата). Для идентификации записей используется первичный ключ. Первичным ключом называется набор полей таблицы, комбинация значений которых однозначно определяет каждую запись в таблице.

Первичный ключ

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

Данные таблицы «Преподаватель»

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

Вторичный ключ

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

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

Между двумя или более таблицами базы данных могут существовать отношения подчиненности. Отношения подчиненности определяют, что для каждой записи главной таблицы {master,называемой еще родительской} может существовать одна или несколько записей в подчиненной таблице {detail, называемой еще дочерней}.

Существует три разновидности связей между таблицами базы данных:

- «один-ко-многим»

- «один-к-одному»

- «многие-ко-многим»

Отношение «один-к-одному» имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице.

Отношение «многие-ко-многим» имеет место, когда:

а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;

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

Отношение «один-ко-многим» имеет место, когда одной записи родительской таблицы может соответствовать несколько записей в дочерней таблице.

Физическая и логическая модели БД

Логическая модель данных . На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД . Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship , диаграммы сущность-связь ). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, т.к. мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.

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

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

Физическая модель данных . На еще более низком уровне находится физическая модель данных. Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано выше, это необязательно. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.

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

При разработке физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно ли выбраны индексы? Насколько много программного кода в виде триггеров и хранимых процедур необходимо разработать для поддержания целостности данных?