Связи между объектами.  

Связи между объектами.

Предыдущая12345678910111213Следующая

Связь между объектом и характеризующим его свойством изображается в виде линии, соединяющей их обозначения. Характер связи между объектом и его свойством может быть различный. Объект может обладать только одним значением какого-то свойства в каждый момент времени. Назовем такие свойства единичными Например, каждый человек может иметь только одну ДАТУ_РОЖДЕНИЯ или СТАЖ_ РАБОТЫ. Для других свойств возможно существование одновременно нескольких их значений у одного и того же объекта (например, свойство ИНОСТРАННЫЙ ЯЗЫК у объекта СОТРУДНИК, если СОТРУДНИК может владеть несколькими иностранными языками). Такое свойство будем называть множественным. При изображении связи между объектом и его свойствами для единичных свойств будем использовать одинарную стрелку, а для множественных свойств - двойную стрелку на конце линии, соединяющей объект с данным свойством (рис. 2.7).

18. Даталогическое проектирование.Спроектировать логическую структуру базы данных означает определить все информационные единицы и связи между ними, задать их имена; если для информационных единиц возможно использование разных типов, то определить их тип. Следует также задать некоторые количественные характеристики, например длину поля.
Любая СУБД оперирует с допустимыми для нее логическими единицами данных, а также допускает использование определенных правил композиции логических структур более высокого уровня из составляющих информационных единиц более низкого уровня. Кроме того, многие СУБД накладывают количественные и иные ограничения на структуру базы данных. Поэтому прежде чем приступить к построению даталогической модели, необходимо детально изучить особенности СУБД, определить факторы, влияющие на выбор проектного решения, ознакомиться с существующими методиками проектирования, а также провести анализ имеющихся средств автоматизации проектирования, возможности и целесообразности их использования.
Хотя даталогическое проектирование является проектированием логической структуры базы данных, на него оказывают влияние возможности физической организации данных, предоставляемые конкретной СУБД. Поэтому знание особенностей физической организации данных является полезным при проектировании логической структуры.
Логическая структура базы данных, а также сама заполненная данными база данных, является отображением реальной предметной области. В связи с этим специфика отображаемой предметной области, отраженная в инфологической модели, оказывает самое непосредственное влияние на выбор проектных решений при проектировании базы данных.
Каждый тип модели данных и каждая разновидность модели, поддерживаемая конкретной СУБД, имеют свои специфические особенности. Вместе с тем имеется много общего во всех структурированных моделях данных и принципах проектирования БД в их среде. Все это дает возможность использовать единый методологический подход к проектированию структуры базы данных.
В БД отражается определенная предметная область. Поэтому процесс проектирования БД предусматривает предварительную классификацию объектов предметной области, систематизированное представление информации об объектах и связях между ними.
На проектные решения оказывают влияние особенности требуемой обработки данных. Поэтому соответствующая информация должна быть определенным образом представлена и проанализирована на начальных этапах проектирования БД.
Данные о предметной области и особенностях обработки информации в ней фиксируются в инфологической модели. В инфологической модели должна быть отображена вся информация, циркулирующая в информационной системе, но это вовсе не означает,что вся она должна храниться в базе данных. В связи с этим одним из первых шагов проектирования является определение состава БД, т.е. перечня тех показателей, которые целесообразно хранить в БД.
При проектировании логической структуры БД осуществляется преобразование исходной инфологической модели в модель данных, поддерживаемую конкретной СУБД, и проверка адекватности полученной даталогической модели отображаемой предметной области.
Для любой предметной области существует множество вариантов проектных решений ее отображения в даталогической модели. Методика проектирования должна обеспечивать выбор наиболее подходящего проектного решения.
Минимальная логическая единица данных (несмотря на их разные названия) семантически для всех СУБД одинакова и соответствует либо идентификатору объекта, либо свойству объекта или процесса.
Связи между сущностями предметной области, отраженные в инфологической модели, могут отображаться в даталогической модели либо посредством совместного расположения соответствующих им информационных элементов, либо путем объявления связи между ними. Связь может передаваться как на внутризаписном, так и межза- писном уровне.
Не все виды связей, существующие в предметной области, могут быть непосредственно отображены в конкретной даталогической модели. Так, многие СУБД не поддерживают непосредственно отношение М:М между элементами. В этом случае в даталоги- ческую модель вводится дополнительный вспомогательный элемент, отображающий эту связь (таким образом отношение М:М как бы разбивается на два отношения 1:М между этим вновь введенным элементом и исходными элементами).
Следует обратить внимание на то, что отношения, имеющие место в предметной области и отражаемые в ИЛМ, могут быть переданы не только посредством структуры базы данных, но и программным путем. Решение о том, какой из способов отображения (структурный/декларативный или программный/процедурный) следует использовать в каждом конкретном случае, будет зависеть от многих факторов, таких как стабильность отображаемой сущности, объем номенклатуры, особенности СУБД, характер обработки данных и др.
При отображении обобщенных объектов в БД возможны разные варианты: хранить информацию обо всем обобщенном объекте в одном файле/таблице; каждому подклассу объектов низшего уровня выделять отдельные самостоятельные файлы/таблицы. Оба эти варианта могут быть использованы в любой СУБД. В первом случае подчеркивается общность объектов разных подклассов, входящих в обобщенный объект. Во втором, напротив, обобщенный объект как единое целое не отображается в структуре базы данных.
Другие способы отображения обобщенных объектов связаны с явным или неявным выделением подклассов в логической структуре БД. Неявное выделение подкласса заключается в том, что в записи отводятся поля для фиксации значений свойств, общих для объектов разных подклассов, и значения признака подкласса, а вместо полей, наличие которых зависит от подкласса, используется одно поле с переменным составом, содержание которого будет зависеть от того, к какому подклассу относится описываемый объект.
Реализация принципа явного выделения подклассов в структуре БД существенно зависит от специфики СУБД.
Как отмечалось выше, характер обработки информации также оказывает влияние на принимаемое проектное решение. Например, рекомендуется хранить вместе информацию, часто обрабатываемую совместно, и, наоборот, разделять по разным файлам информацию, не использующуюся одновременно. Информацию, используемую часто, и информацию, частота обращения к которой мала, также следует хранить в разных файлах, причем последнюю может оказаться выгодным вынести в архивные файлы.
При переходе от инфологической модели к даталогической следует иметь в виду, что инфологическая модель включает в себя всю информацию о предметной области, необходимую и достаточную для проектирования БД. Это не означает, что все сущности, зафиксированные в ИЛМ, должны в явном виде отражаться в даталогической модели. Прежде чем строить даталогическую модель, необходимо решить, какая информация будет храниться в базе данных. Например, в инфологической модели должны быть отражены вычисляемые показатели, но вовсе не обязательно, что они должны храниться в базе данных.
Существуют разные подходы к определению состава показателей, которые должны храниться в базе данных. Согласно одному из них в БД должны храниться только исходные показатели, все производные показатели должны быть получены расчетным путем в момент реализации запроса (этот подход иногда называют принципом синтезирования, имея в виду возможность «синтезировать» требуемые показатели из хранимых в информационной базе данных).
Такой подход имеет очевидные достоинства: 1) простота и однозначность в принятии решения «что хранить»; 2) отсутствие неявного дублирования информации со всеми вытекающими из этого последствиями (меньше объем памяти, чем при хранении как исходных, так и производных показателей, проще проблемы контроля целостности данных); 3) потенциальная возможность получить любой расчетный показатель, а не только те, которые хранятся в БД.
При принятии решения о хранении расчетных показателей принимаются во внимание несколько факторов.
Рассмотрим некоторую гипотетическую предметную область, представляющую собой учебное заведение. Учащимся этого заведения начисляется стипендия. Существует четкий алгоритм начисления стипендии. Предположим, что он выглядит следующим образом:
1. Стипендия начисляется только тем, кто успешно сдал все экзамены в сессию (т.е. сдал в срок и не получил неудовлетворительных оценок), а также учащимся, имеющим детей.
2. Известен размер обычной стипендии.
3. Тем, кто не имеет удовлетворительных оценок, назначается стипендия на 25% выше, чем обычная.
4. Тем, кто имеет только отличные оценки, стипендия увеличивается на 50% от размера обычной стипендии. Предположим также, что размер стипендии не может изменяться в течение семестра. Таким образом, размер стипендии является вычисляемым показателем и может не храниться в базе данных, а каждый раз определяться расчетным путем. Однако в рассматриваемой ситуации его все-таки лучше хранить в БД по следующим основным причинам:
а) полученная величина многократно используется в дальнейшем;
б) алгоритм определения размера стипендии имеет достаточно сложную логику, и для выполнения расчета требуется просмотреть несколько файлов (некоторые из них являются большими по объему, что также замедляет процесс обработки);
в) размер стипендии не должен изменяться в течение семестра. Кроме того, имея реальный файл «Начисленная стипендии», легче контролировать его полноту и достоверность.
Предположим также, что к БД достаточно часто обращаются с запросом о среднем балле какого-либо студента или среднем балле по той или иной дисциплине и т.п.
При изменении любой оценки или получении новой средний балл меняется, и если вы вдруг решите хранить и среднюю величину, и исходные оценки, то обеспечение их соответствия представляет собой некоторую проблему. При правильной организации файлов вычисление средней величины во время исполнения запроса не представляет проблемы ни с точки зрения времени обработки, ни с точки зрения задания запроса. Поэтому хранить средний балл не следует.



Особенности ДЛМ.

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

Реляционная модель данных. Основные понятия и определения.

термин "реляционная модель данных". Проект System R был разработан в исследовательской лаборатории корпорации IBM. Этот проект был задуман с целью доказать практичность реляционной модели. Реляционные СУБД относятся к СУБД второго поколения.

Цели создания реляционной модели данных:

1. Обеспечение более высокой степени независимости от данных.

2. Создание прочного фундамента для решения проблем непротиворечивости и избыточности данных.

3. Расширение языков управления данными за счет включения операций над множествами.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД.

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

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие:

1. реляционная БД – набор нормализованных отношений;

2. отношение – файл, плоская таблица, состоящая из столбцов и строк; таблица, в которой каждое поле является атомарным;

3. домен – совокупность допустимых значений, из которой берется значение соответствующего атрибута определенного отношения. С точки зрения программирования, домен – это тип данных;


8480876575123198.html
8480884588234471.html
    PR.RU™