ЛЕКЦИЯ

Логические модели данных.

Иерархические, сетевые, реляционные модели данных.

Принципы построения.

Преимущества и недостатки

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

11.1. О понятии «модель данных»

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

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

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

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

Итак, модель данных – модель логического уровня проектирования БД. Ее можно рассматривать как сочетание трех компонентов (слайд 2 ):

1. Структурный компонент, т.е. набор правил, по которым может быть построена БД.

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

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

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

Существуют три основных типа логических моделей данных на основе записей ( слайд 3 ):

- реляционная модель данных (relational data model );

- сетевая мо дель данных (network data model );

- иерархическая модель данных (hierarchical data model ).

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

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

Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами. На слайде (слайд 4 ) показан пример реляционной схемы, содержащей сведения о кафедрах ВУЗа и кадровом составе. Например, из таблицы «Кадровый состав» видно, что сотрудник Иванов И.И. работает в должности заведующего кафедрой 22, которая, согласно данным из таблицы «Структура», расположена в корпусе А, в комнате 322. Здесь важно отметить, что между отношениями «Кадровый состав» и «Структура» существует следующая связь: сотрудник работает на кафедре. Однако между этими двумя отношениями нет явно заданной связи: ее существование можно заметить, только зная, что атрибут Каф в отношении «Кадровый состав» эквивалентен атрибуту Каф в отношении «Структура».

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

На слайдах (слайды 5, 6 ) представлена реляционная модель данных для ПрО «сотрудники-проекты-детали-поставщики».

11.3. Сетевая модель данных

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

Самой популярной сетевой СУБД является система IDMS / R фирмы Computer Associates .

На слайдах (слайды 8, 9 ) представлены варианты сетевой модели данных для ПрО «сотрудники-проекты-детали-поставщики».

11.4. Иерархическая модель данных

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

Самой распространенной иерархической СУБД является система IMS корпорации IBM , хотя она обладает также некоторыми другими неиерархическими чертами.

На слайдах (слайды 11, 12 ) представлена варианты иерархической модели данных для ПрО «сотрудники-проекты-детали-поставщики».

11.5. Преимущества и недостатки моделей

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

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

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

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

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

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

11.6. Документальные системы и интеграция моделей

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

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

Аннотация

В данной курсовой работе описывается проектирование базы данных центральной городской больницы и ее реализация в 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

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 (цитируется по...

BPwin и Erwin. CASE-средства для разработки информационных систем Маклаков Сергей Владимирович

2.1.1. Физическая и логическая модель данных

2.1.1. Физическая и логическая модель данных

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

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

Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.

Масштабирование. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-серверной ИС. Заметим, однако, что формальный перенос структуры "плоских" таблиц на реляционную СУБД обычно неэффективен. Для того чтобы извлечь выгоды от перехода на клиент-серверную технологию, структуру данных следует модифицировать. Процессы прямого и обратного проектирования будут рассмотрены ниже.

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

Рис. 2.1. Переключение между логической и физической моделью

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

Из книги Собираем компьютер своими руками автора Ватаманюк Александр Иванович

Модель ISO/OSI и протоколы передачи данных Главной в стандартизации сетей и всего, что к ним относится, является модель взаимодействия открытых систем (Open System Interconnection, OSI), разработанная международной организацией по стандартизации (International Standards Organization, ISO). На практике

Из книги Справочное руководство по C++ автора Страустрап Бьярн

R.5.15 Логическая операция ИЛИ логическое-выражение-ИЛИ: логическое-выражение-И логическое-выражение-ИЛИ || логическое-выражение-ИОперации || выполняются слева направо. Результат операции 1, если один из ее операндов отличен от нуля, иначе результат - 0. В отличие от | при

Из книги Язык программирования С# 2005 и платформа.NET 2.0. автора Троелсен Эндрю

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

Из книги Обработка баз данных на Visual Basic®.NET автора Мак-Манус Джеффри П

ГЛАВА 4 Модель ADO.NET: провайдеры данных Порой кажется, что не успели еще разработчики приложений баз данных привыкнуть к новой технологии, как компания Microsoft предложила совершенно новую модель доступа к базам данных. В этой главе основное внимание уделяется модели ADO.NET,

Из книги TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) автора Фейт Сидни М

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

Из книги Инфраструктуры открытых ключей автора Полянская Ольга Юрьевна

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

Из книги Моделирование бизнес-процессов с BPwin 4.0 автора Маклаков Сергей Владимирович

3.1. Модель данных и ее соответствие модели процессов Функциональная модель BPwin является основой для построения модели данных. Действительно, не имея информации о том, как работает предприятие, бессмысленно строить модель данных. Для построения модели данных удобно

Из книги Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ автора Борри Хелен

Модель данных <> база данных Тот "мир", который был получен в процессе описания и анализа, является черновиком для структур ваших данных. Считается, что логическая модель должна описывать отношения и наборы. Обычная ошибка (и западня, присущая всем инструментам CASE) слепо

Из книги Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil автора Ковязин Алексей Николаевич

Из книги IT-безопасность: стоит ли рисковать корпорацией? автора Маккарти Линда

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

Из книги Восстановление данных на 100% автора Ташков Петр Андреевич

Физическая структура базы данных Зачем изучать физическую структуру базы данных? Говоря о физической структуре базы данных InterBase, обычно подразумевают то что представляют собой данные с точки зрения низкоуровневой организации данных - вплоть до уровня байтов. Многие

Из книги Операционная система UNIX автора Робачевский Андрей М.

Из книги автора

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

Из книги автора

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

Из книги автора

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

Из книги автора

Виртуальная и физическая память Оперативная память является, пожалуй, одним из наиболее дорогих компонентов компьютерной системы. Ранние системы UNIX имели в своем распоряжении 64 Кбайт оперативной памяти, и это количество было явно недостаточным, современные компьютеры

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

Рисунок 1 – логическая модель

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

2.2 Сущности

Данная БД содержит 16 сущностей. Разберем каждую из них и связи между ними.

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

Сущность Статус также содержит два атрибута: Ном_ст – порядковый номер статуса (ключевой атрибут), и Статус – наименование статуса. Статус может принимать два значения: студент и аспирант.

Сущность Факультет содержит информацию о факультетах. Первый атрибут (ключевой) Ном_фак – порядковый номер факультета, второй атрибут Факультет – сокращенное наименование факультета.

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

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

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

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

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

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

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

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

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

Еще одна связующая сущность – Студ_комн . Предназначена для хранения номера переселения студентов, номера студенческого билета, номера комнаты и дат заселения и выселения.

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

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

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