Даталогическое проектирование

Материал из ПИЭ.Wiki

Перейти к: навигация, поиск

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


Содержание

Исходные данные для даталогического проектирования

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

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

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

Результат даталогического проектирования

Конечным результатом даталогического проектирования является' описание логической структуры базы данных на ЯОД. Однако если проектирование выполняется «вручную», то для большей наглядности сначала строится схематическое графическое изображение структуры базы данных. При этом должно быть обеспечено однозначное соответствие между конструкциями языка описания данных и графическими обозначениями информационных единиц и связей между ними. Графическое представление используется и при автоматизированном проектировании структуры базы данных как интерфейсное средство общения с проектировщиком, и при документировании проекта.

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

Подход к даталогическому проектированию

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

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

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

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

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

Для любой предметной области существует множество вариантов проектных решений ее отображения в даталогической модели. Методика проектирования должна обеспечивать выбор наиболее подходящего проектного решения.

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

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

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

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

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

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

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

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

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

Как отмечалось выше, в ИЛМ описывается не отдельный объект, а класс объектов. Но в редких случаях бывает, что класс включает в себя только один экземпляр объекта. Например, если предметной областью является какой-то конкретный институт, то класс объектов ИНСТИТУТ будет содержать только один экземпляр объекта. Таким «вырожденным» классам объектов обычно не ставится в соответствие отдельный файл базы данных.

Определение состава базы данных

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

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

Такой подход имеет очевидные достоинства:

  • простота и однозначность в принятии решения «что хранить»;
  • отсутствие неявного дублирования информации со всеми вытекающими из этого последствиями (меньше объем памяти, чем при хранении как исходных, так и производных показателей; проще проблемы контроля целостности данных);

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

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

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

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

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

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

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

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

Предположим также, что к БД достаточно часто обращаются с запросом о среднем балле какого-либо студента или среднем балле по той или иной дисциплине и т.п.

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

Введение искусственных идентификаторов

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

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

2. Если объект участвует во многих связях/процессах, то для их отображения создается несколько файлов/таблиц, в каждом из которых повторяется идентификатор объекта. Для того чтобы не использовать во всех файлах длинный естественный идентификатор объекта, можно ввести и использовать более короткий код. Например, вместо длинных наименований продукции обычно используются их кодовые обозначения. Это не только сэкономит память, но и сократит трудоемкость ввода информации (хотя последнего можно достичь и другим путем).

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

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

Особенности даталогических моделей

Внутризаписная структура

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

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

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

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

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

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

Межзаписная структура

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

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

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

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

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

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

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

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

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

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

По сути понятия «родитель» — «ребенок» в иерархических моделях, файл-«владелец» — файл-«член» в сетевых моделях и связь «ключ» — «внешний ключ» в реляционных моделях передают одно и то же явление — наличие связи 1 : М между записями соответствующих файлов.

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

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


Переход от ER-модели к схеме реляционной базы данных

1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы. Каждый простой атрибут становится столбцом таблицы с тем же именем: R1 (И1 , А1 , А2 , А3 ).

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

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

Некоторые СУБД (Access, Paradox и др.) позволяют автоматически генерировать в качестве ключа таблицы поле типа «счетчик». Этот искусственный код можно использовать для простых объектов, если в предметной области не предполагается применение другой системы кодирования (ОКПО, ОКОНХ, ИНН).

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

3. Каждому из многозначных атрибутов ставится в соответствие отношение, полями которого будут идентификатор, выбранный в качестве первичного ключа, и многозначный атрибут. Ключ этого отношения будет составным, включающим оба эти атрибута. Для многозначных атрибутов МА4 и МА5 будут созданы отношения: R2 (И1 , МА4 ) и R3 (И1 ,МА5 ).

4. Если сущность имеет необязательный атрибут, возможны два варианта:

  • если таким свойством обладают многие экземпляры объекта, его можно хранить как обычный атрибут в той же таблице (столбец может содержать неопределенные значения);
  • если свойством обладает малое число экземпляров, то можно выделить отношение, включающее идентификатор и соответствующий атрибут: R4 (И1 , НА6 ). Отношение будет содержать столько строк, сколько объектов имеет свойство.

5. Если сущность имеет составной атрибут, то возможны два варианта:

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

Выбор варианта зависит от характера обработки данных. При реализации запросов проще объединить поля, чем выделить часть поля. Если предполагается использование компонентов атрибута, лучше вариант 2, иначе – вариант 1.

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

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

R3 (И1 , И2 , А1 , А2 ).

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

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

R1 (И1 , А1 , И2 )

R2 (И2 , А2 )

или

R1 (И1 , А1 )

R2 (И2 , А2 , И1 ).

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

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

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

7. Преобразование бинарной связи один-ко-многим (1:N) зависит только от класса принадлежности N-связной сущности. Если он является обязательным, то можно использовать два отношения (по одному для каждой сущности). В отношение для N-связной сущности добавляется идентификатор 1-связной сущности:

R1 (И1 , А1 )

R2 (И2 , А2 , И1 ).

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

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

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

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

9. В случае N-арной связи необходимо использовать (n+1) отношение – по одному для каждой сущности, и одно для связи. Идентификатор каждой сущности станет первичным ключом соответствующего отношения. Отношение, порождаемое связью, будет иметь среди своих атрибутов ключи каждой сущности. Если связь имеет атрибуты, то они становятся атрибутами отношения связи. Например:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И3 , А3 )

R4 (И1 , И2 , И3 , АС4 ).

10. Обобщающей сущности соответствует одно отношение, причем ключ сущности становится ключом отношения. Этому отношению приписываются общие для всех ролевых сущностей атрибуты. Ролевые элементы и связи, их соединяющие, порождают такое число отношений, которое определяется ранее описанными правилами, причем каждая роль трактуется как обычная сущность. Связываются отношения с помощью ключевого атрибута. Каждому значению ключевого атрибута ролевой сущности соответствует одна запись в обобщающем отношении с таким же значением ключа.

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

Ссылки

Просмотры
Инструменты

Besucherzahler russian mail order brides
счетчик посещений
Rambler's Top100
Лингафонные кабинеты  Интерактивные доски  Интерактивная приставка Mimio Teach