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

Различают 4 типа связи :

1:N (один ко многим).

N:1 (многие к одному).

N:N(многие ко многим).

Помимо «тип связи» используется понятие«степень связи» . В инфологической модели помимо степени связи надо указыватьпринадлежность связи .

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

Обязательный класс принадлежности.

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

Необязательный класс принадлежности.

Если некоторые объекты 1-го класса могут не участвовать в связях с объектами 2-го класса, то класс принадлежности объектов 1-го класса называются необязательными .

8.ER-диаграммы и их разновидности. Понятия сущности, связи, атрибуты.

Преподаватель читает курс.

Связь именуется глаголом «читает».

Связь между объектами может быть выражена 2 способами представления с помощью ER-диаграмм.

Диаграмма ER- экземпляра.

По номеру курса можно однозначно идентифицировать курс.

Диаграмма ER- типа

Тип связи 1 к 1.

Класс принадлежности объектов и для П и для К необязательный.

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

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

Связь – представляет собой соединение между двумя или более сущностями.

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

Атрибут – свойство сущности.

Атрибутами сущности «Преподаватель» является номер, ФИО, дата рождения, должность.

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

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

Ключом связи «Читает» является набор сущностей П и К <НП, НК>.

К
аждый преподаватель читает 1 курс, каждый курс читается одним преподавателем.

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

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

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

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

9.Описание сложных объектов. Составные, обобщенные, агрегированные объекты

По степени сложности различают простые и сложные объекты.

Простой объект – объект, который рассматривается как неделимый.

Сложный объект – объект, который представляет собой объединение других объектов, также выделяемых в предметной области.

Все объекты активны.

Пользовательское управление группами окон.

Типы окон, ориентированные на задачу.

Мгновенная фиксация изменений.

Динамические иконки, отражающие состояние объекта.

Прямое манипулирование.

Объединение объектов.

Композиция объектов и контейнеры.

Множественный согласованный просмотр объектов.

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

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

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

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

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

Типы связей между объектами .

Наиболее общими типами отношений являются наборы (Collection), объединения (Constraints), и композиции (Composites).

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

Объединение отражает более тесное отношение между объектами, при котором изменение объекта влияет на некоторый другой объект в наборе. Простейший пример такого отношения – изменение формата соседней страницы при добавлении текста на предыдущей странице.

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

Еще один распространенный тип отношений между объектами – контейнер.

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

Рассмотренные выше аспекты обуславливают необходимость отнесения каждого объекта к тому или иному типу (классу) объектов. Объекты одного типа имеют аналогичные свойства и поведение.

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

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

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

Диаграмма ER-типа:

Упрощения:

1. Рассматриваются только те жители, которые имеют квартиру.

2. Житель может быть зарегистрирован только в одной квартире.

3. Учитываются только населенные квартиры, в которых зарегистрированы жители.

4. В одной квартире могут быть зарегистрированы несколько жителей.

5. Для одной квартиры один номер телефона.

6. Не во всякой квартире может быть телефон.

7. Имеются жители без источника дохода (дети).

8. У одного жителя может быть несколько источников дохода.

9. Разные виды дохода у разных жителей.

10. Имеются виды доходов, которые не используются.

Конец работы -

Эта тема принадлежит разделу:

Сравнение однотабличной и многотабличной баз данных

На сайте сайт читайте: "сравнение однотабличной и многотабличной баз данных"

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Твитнуть

Все темы данного раздела:

Компоненты БнД
Словарь данных – «хранилище» метаинформации. Метаинформация – информаци

Этап определения подсхем
В некоторых СУБД имеется возможность описать логическую структуру БД с точки зрения конкретной группы пользователей. Такая модель называется внешней, а ее описание – подсхе

Инфологическое моделирование предметной области. Состав инфологической модели (ИЛМ)
1-2. Описание предметной области представляется с помощью какой-либо знаковой системы, поэтому в

Описание объектов и их свойств. Разновидности свойств объектов
Класс объектов – совокупность объектов, обладающих одинаковым набором свойств. Классы объектов могут быть как материальными, так и абстрактными (например, предметы, по кот

Диаграмма ER-типа
Тип связи 1 к 1. Класс принадлежности объектов и для П и для К необязател

Разновидности сложных объектов
1. Составной объект. 2. Обобщенный объект. 3. Агрегированный объект. Составной объект

Определение состава БД
Один из подходов к определению состава БД – принцип синтезирования. Суть:В БД должны храниться только исходные показатели. Все производные показатели долж

Разновидности даталогических моделей (ДЛМ)
По способу установления связей между данными различают следующие модели: Реляционная модель, Иерархическая модель, Сетевая модель, Объектно-ориентированная модель. Реляцио

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

Метод проектирования РБД на основе ИЛМ (правила 1-12)
1. Для каждого простого объекта и его единичных свойств строится отношение, атрибуты которого являются идентификаторами объекта и реквизиты соответствуют каждому из единичных свойс

Определение состава БД и отношений
Принцип синтезирования: В состав БД включают атрибуты всех сущностей + вычисляемый доход SumD. БД состоит из 5 отношений: PERSON (Nom, FIO, Rdate, Pol, S

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

Structured Query Language
Конкретные реализации SQL учитывают требования стандарта, но предоставляют и дополнительные возможности (SQL1, SQL2(1992), SQL3(1999)) SQL можно использовать в 2-х режимах: 1. Инт

Предложение Select
В качестве ТРЗ может быть имя столбца, константа, выражение. Имя столбца идентифицирует один из столбцов, содержащихся в таблице, которая указана в предложении FROM. Оно может быть указано

Указывает, какие строки следует отбирать. Задается условие поиска, как критерий отбора. Виды условий поиска: 1. Сравнение. =, <>, <, >, <=, >=. 2. Прове

Составные условия поиска. Таблицы истинности
AND true false null OR true

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

Запросы с группировкой и ограничения на них
Select ADR, AVG(SUMD) FROM PERSON GROUP BY ADR 1. Сведения о жителях в таблице Person делятся на группы – по одной группе на каждую квартиру. В каждой группе все квартиры имеют 1

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

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

Проверка на существование результатов вложенного запроса
SELECT *FROM PERSON WHERE EXISTS (SELECT ID FROM HAVE_D, PROVIT WHERE PROVIT.ID

Добавление новых элементов
Наименьшей единицей информации, которую можно добавить в базу данных, является одна строка. Существует 2 способа добавления новых строк: 1) однострочный оператор INSERT, включающи

Удаление существующих данных
Наименьшей единицей информации, которую можно удалить из БД является 1 строка. Для удаления строк из 1-й таблицы используется оператор DELETE. DELETE FROM – имя_таблицы -------------------

Условия уникальности данных
Возьмем таблицу PERSON, опишем ее структуру: CREATE TABLE PERSON (INTERBASE) (NOM INTEGER NOT N

Изменение определения таблицы
ALTER TABLE служит для: 1. добавить определение нового столбца. 2. изменить значение по умолчанию. 3. изменить или удалить первичный ключ таблицы.

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

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

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

Связь один-к-одному (1:1) существует, когда один экземпляр одного объекта связан с единственным экземпляром другого. Связь уникальна слева направо, так и справа налево.

руководит

Предприятие Директор

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

Состоит из

Город Район

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

Студент (фамилия, № зачетной книжки. Факультет) Предмет (название, кол-во часов)

Отношение «много-к-одному» (М:1) схоже с отношение «один-ко-многим». Связь является уникальной лишь слева направо.

Фамилия студента (М:1) Номер группы

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

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

Рис. 48 Пример оформления концептуальной модели

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

1. Основные понятия и термины к теме
“ИНФОРМАЦИОННАЯ МОДЕЛЬ – ОСНОВА ПОСТРОЕНИЯ
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ.

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

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

@ Ядром информационной системы являются хранимые в ней данные . На любом предприятии данные различных отделов, как правило, пересекаются, то есть используются в нескольких подразделениях или вообще являются общими. Например, для целей управления часто нужна информация по всему предприятию. Заказ комплектующих невозможен без наличия информации о запасах. Хранящиеся в информационной системе данные должны быть легко доступны в том виде, в каком они нужны для конкретной производственной деятельности предприятия. При этом не имеет существенного значения способ хранения данных. Сегодня на предприятии мы можем встретить систему обработки данных традиционного типа, в которой служащий вручную помещает данные в скоросшиватель, и рядом с ней - современную систему с применением самой быстродействующей ЭВМ, сложнейшего оборудования и программного обеспечения. Несмотря на поразительную несхожесть, обе эти системы обязаны предоставлять достоверную информацию в определенное время, определенному лицу, в определенном месте и с ограниченными затратами.

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

@ Предметной областью называется часть реальной системы, представляющая интерес для данного исследования.

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

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

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

@ Объектом называется элемент информационной системы, информацию о котором мы сохраняем. В реляционной теории баз данных объект называется сущностью.

Объект может быть реальным (например, человек, какой-либо предмет или населенный пункт) и абстрактным (например, событие, счет покупателя или изучаемый студентами курс). Так, в области продажи автомобилей примерами объектов могут служить МОДЕЛЬ АВТОМОБИЛЯ, КЛИЕНТ и СЧЕТ. На товарном складе - это ПОСТАВЩИК, ТОВАР, ОТПРАВЛЕНИЕ и т. д. Каждый объект обладает определенным набором свойств, которые запоминаются в информационной системе. При обработке данных часто приходится иметь дело с совокупностью однородных объектов, например таких, как служащие, и записывать информацию об одних и тех же свойствах для каждого из них.

@ Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств.

Таким образом, для объектов одного класса набор свойств будет одинаков, хотя значения этих свойств дл я каждого объекта, конечно, могут быть разными. Например, класс объектов МОДЕЛЬ свойств дл я каждого объекта, конечно, могут быть разными. Например, класс объектов МОДЕЛЬ АВТОМОБИЛЯ будет иметь одинаковый набор свойств, описывающих характеристики автомобилей, и каждая модель будет иметь различные значения этих характеристик.

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

@ Атрибут - это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов.

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

Рис. 1.1. Три области представления данных.

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

Мы постараемся избегать последнего термина, так как с развитием реляционной теории “отношением” наряду с термином “связь” часто стали называть связи между таблицами. Каждая запись одной таблицы состоит из конечного (и одинакового!) числа полей , причем конкретное поле каждой записи одной таблицы может содержать данные только одного типа.

@ Значения данных представляют собой действительные данные, содержащиеся в каждом элементе данных.

Элемент данных “НАИМЕНОВАНИЕ МОДЕЛИ” может принимать такие значения, как “Voyager"96 3.8 Grand ”, “Continental 4.6” или “Crown Victoria 4.6” . В зависимости от того, как элементы данных описывают объект, их значения могут быть количественными, качественными или описательными. Информацию о некоторой предметной области можно представить с помощью нескольких объектов, каждый из которых описывается несколькими элементами данных. Принимаемые элементами данных значения называются данными .

@ Единичный набор принимаемых элементами данных значений называется экземпляром объекта . Объекты связываются между собой определенным образом.

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

Некоторые элементы данных обладают важным для построения информационной модели свойством. Если известно значение, которое принимает такой элемент данных объекта, мы можем идентифицировать значения, которые принимают другие элементы данных этого же объекта. Например, зная уникальный номер модели автомобиля - 7, мы можем определить, что это “Voyager" 96” и что рабочий объем двигателя у данной модели “ 3778” .

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

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

@ Первичный ключ - это атрибут (или группа атрибутов), которые единственным образом идентифицируют каждую строку в таблице.

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

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

Например, для объекта “СЛУЖАЩИЙ”, который имеет атрибуты “ИДЕНТИФИКАТОР СЛУЖАЩЕГО”, “ФАМИЛИЯ”, “ИМЯ” и “ОТЧЕСТВО”, группа атрибутов “ФАМИЛИЯ”, “ИМЯ”, “ОТЧЕСТВО” может являться альтернативным ключом по отношению к атрибуту “ИДЕНТИФИКАТОР СЛУЖАЩЕГО” (в предположении, что на предприятии не работают полные тезки).

@ Внешний ключ - это атрибут таблицы, являющийся первичным ключом другой таблицы.

Например, атрибут "НОМЕР МОДЕЛИ" объекта АВТОМОБИЛЬ может быть внешним ключом по отношению к объекту "MODEL" (Модель автомобиля).

@ Запись данных - это совокупность значений связанных элементов данных.

На рис. 1.2. такими элементами данных являются уникальный ключ и наименование модели, рабочий объем, количество цилиндров и мощность двигателя. Например, одна из записей –“7 Voyager’96 3.8 Grand 3778 6 164,0” . Эта строка представляет собой значения, которые принимают элементы данных объекта МОДЕЛЬ АВТОМОБИЛЯ (MODEL). Записи хранятся на некотором носителе, в качестве которого может выступать человеческий мозг, лист бумаги, память ЭВМ, внешнее запоминающее устройство и т. д.

MODEL
УНИКАЛЬНЫЙ КЛЮЧ МОДЕЛИ	Наименование модели	Рабочий объем (куб. см.)	Мощность (л.сил)
	GMC Jimmy 4.3
7	Voyager’96 3.8 Grand	3778	164,0
	Stealth 3.0
	348 Spider 3.4

Рис.1.2. Записи данных объекта MODEL.

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

@ Тип данных характеризует вид хранящихся данных.

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

@ Связь - это функциональная зависимость между сущностями.

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

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

Тип связи (идентифицирующая, не идентифицирующая)

Родительская сущность;

Дочерняя (зависимая) сущность;

Мощность связи (cordiality );

Допустимость пустых (null ) значений.

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

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

Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n .

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

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

@ Правила позволяют вызывать выполнение заданных действий при изменении или добавлении данных в базу данных (БД) и тем самым контролировать истинность помещаемых в нее данных.

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

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

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

@ Нормализация отношений - это процесс построения оптимальной структуры таблиц и связей в реляционной БД.

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

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

@ Обеспечением целостности базы данных называется система мер, направленных на поддержание правильности данных в базе данных в любой момент времени.

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

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

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

2. Последовательность создания информационной модели

Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей (рис. 2.1). Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы функциональности, требуемой для разрабатываемой системы, и снизит вероятность ее переделки в дальнейшем. Требования отдельных пользователей интегрируются в едином “обобщенном представлении”. Последнее называют концептуальной моделью.

@ Концептуальная модель представляет объекты и их взаимосвязи без указания способов их физического хранения.

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

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

@ Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения.

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

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

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

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

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

3. Взаимосвязи в модели

Взаимосвязь выражает отображение или связь между двумя множествами данных. Различают взаимосвязи типа «один к одному », «один ко многим » и «многие ко многим ». В рассматриваемой задаче по автоматизации управления работой дилерапопродаже легковых автомобилей, если клиент производит заказ на покупку автомобиля впервые, осуществляется первичная регистрация его данных и сведений о сделанном заказе. Если же клиент производит заказ повторно, осуществляется регистрация только данного заказа. Вне зависимости от того, сколько раз данный клиент производил заказы, он имеет уникальный иденти­фикационный номер (уникальный ключ клиента). Информация о каждом клиенте включает наименование клиента, адрес, телефон, факс, фамилию, имя, отчество, признак юридического лица и примечание. Таким образом, атрибутами объекта КЛИЕНТ являются «УНИКАЛЬНЫЙ КЛЮЧ КЛИЕНТА», «НАИМЕНОВАНИЕ КЛИЕНТА», «АДРЕС КЛИЕНТА» и т. д. Следующий представляющий для нас интерес объект - МОДЕЛЬ АВТОМОБИЛЯ. Этот объект имеет атрибуты «УНИКАЛЬНЫЙ КЛЮЧ МОДЕЛИ», «НАИМЕНОВАНИЕ МОДЕЛИ» и т.д. Третий рассматриваемый объект - ЗАКАЗ. Его атрибутами являются «НОМЕР ЗАКАЗА», «КЛЮЧ КЛИЕНТА» и «КЛЮЧ МОДЕЛИ». И четвертый рассматриваемый объект - ПРОДАВЕЦ. Его атрибутами являются «УНИКАЛЬНЫЙ КЛЮЧ ПРОДАВЦА», «ИМЯ ПРОДАВЦА», «ФАМИЛИЯ» и «ОТЧЕСТВО».

Взаимосвязь «один к одному» (между двумя типами объектов)

Мысленно вернемся к временам планово-распределительной экономики. Допустим, в определенный момент времени один клиент может сделать только один заказ. В этом случае между объектами КЛИЕНТ и ЗАКАЗ устанавливается взаимосвязь «один к одному », обозначаемая одинарными стрелками, как это показано на рис. 2.2,а.

Рис. 2.2. Взаимосвязи между двумя объектами: а) «один к одному»; б) «один ко многим»; в) «многие ко многим»

Рис. 2.3. Взаимосвязь между данными при отношении «один к одному».

Взаимосвязь «один ко многим» (между двумя типами объектов).

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

В этом случае одной записи данных первого объекта (его часто называют родительским или основным) будет соответствовать несколько записей второго объекта (дочернего или подчиненного). Взаимосвязь «один ко многим» очень распространена при разработке реляционных баз данных. В качестве родительского объекта часто выступает справочник, а в дочернем хранятся уникальные ключи для доступа к записям справочника. В нашем примере в качестве такого справочника можно представить объект КЛИЕНТ, в котором хранятся сведения о всех клиентах. При обращении к записи для определенного клиента нам доступен список всех покупок, которые он сделал и сведения о которых хранятся в объекте МОДЕЛЬ АВТОМОБИЛЯ, как это показано на рис. 2.4. В случае, если в дочернем объекте будут какие-то записи, для которых нет соответствующих записей в объекте КЛИЕНТ, то мы их не увидим. В этом случае говорят, что объект содержит потерянные (одинокие) записи. Это не допустимо, и в дальнейшем вы узнаете, как избегать подобных ситуаций.

Рис. 2.4. Взаимосвязь между данными при отношении «один ко многими».

Если мы будем просматривать записи объекта МОДЕЛЬ АВТОМОБИЛЯ, то в объекте КЛИЕНТ мы сможем получить данные о клиенте, купившем данный автомобиль (см. рис. 2.4). Обратите внимание, что для потерянных записей сведений о клиенте мы не получим.

Взаимосвязь «многие ко многими (между двумя типами объектов).

В рассматриваемом примере каждый продавец может обслуживать нескольких клиентов. С другой стороны, приобретая автомобили в различное время, каждый клиент вполне может быть обслужен различными продавцами. Между объектами КЛИЕНТ и ПРОДАВЕЦ существует взаимосвязь «многие ко многим». Такая взаимосвязь обозначается двойными стрелками, как это показано на рис. 2.2, в.

На рис. 2.5 приведена схема, по которой в этом случае будут взаимосвязаны данные. При просмотре данных в объекте КЛИЕНТ мы сможем узнать, какие продавцы обслуживали определенного клиента. Однако в объекте ПРОДАВЕЦ в этом случае нам придется завести несколько записей для каждого продавца. Каждая строчка будет соответствовать каждому обслуживанию продавцом кли­ента. При таком подходе мы столкнемся с серьезными проблемами. Например, не сможем ввести в объект ПРОДАВЕЦ уникальный ключ для каждого продав­ца, так как неизбежно один продавец будет обслуживать нескольких клиентов, и в этом случае у нас появится несколько записей для одного и того же продавца.

Рис. 2.5. Взаимосвязь между данными при отношении «многие ко многими

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

Рис. 2.6. Отображение взаимосвязи между данными при отношении «многие ко многим» с помощью промежуточного объекта

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

Взаимосвязь «один к одному» (между двумя атрибутами)

Мы предполагаем, что ключ (номер) клиента является его уникальным идентификатором, то есть он не изменяетсяпри последующих поступлениях заказов от данного клиента. Если наряду с номером клиента в базе данных хранится и другой его уникальный идентификатор (например, номер паспорта),то между такими двумя уникальными идентификаторами существует взаимосвязь «один к одному». На рис. 2.7,а эта взаимосвязь обозначается одинарными стрелками .

Взаимосвязь «один ко многим» (между двумя атрибутами)

Имя клиента и его номер существуют совместно. Клиентов с одинаковыми именами может быть много, но все они имеют различные номера. Каждому клиенту присваивается уникальный номер. Это означает, что данному номеру клиента соответствует только одно имя. Взаимосвязь «один ко многим» обозначается одинарной стрелкой в направлении к «одному» и двойной стрелкой в направлении ко «многим» (рис.2.7, б ).

Взаимосвязь «многие ко многим» (между двумя атрибутами)

Несколько клиентов с одинаковыми именами могли быть обслужены несколькими продавцами. Несколько продавцов с одинаковыми именами могли получить заказы от нескольких клиентов. Между атрибутами «имя клиента» и «имя продавца» существует взаимосвязь «многие ко многим». Мы обозначаем эту взаимосвязь двойными стрелками (рис. 2.7,в ).

а)

б)

в)

Рис. 2.7. Взаимосвязи между двумя атрибутами:
а) взаимосвязь «один к одному»; б) взаимосвязь «один ко многим » в) взаимосвязь «многие ко многим »

Типы моделей данных

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, - подчиненными (рис. 2.8). Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объекта. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов. Таким образом, взаимосвязи между объектами напоминают взаимосвязи в генеалогическом дереве за единственным исключением: для каждого порожденного (подчиненног o ) типа объекта может быть только один исходный (главный) тип объекта. На рис. 2.8 узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и т. д. уровнях.

Рис. 2.8. Схема иерархической модели данных.

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

Рис.2.9. Схема сетевой модели данных.

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

Рис. 2.10. Схема реляционной модели данных.