Правила оптимизации er-модели.
|
|
Сущности А и В, соединенные связью , сливаются, т.е. в общую сущность собираются все атрибуты и все связи. NB! Возможно придется изменить имя сущности и перенесенных атрибутов! |
|||||||||||
|
Не делается если связь подвижная, т.е. в разное время могут быть соединены разные экземпляры А и В. |
||||||||||||
|
|
Циклы могут быть признаком избыточности или ошибок. Анализ цикла: найти «Источники» (сущности, откуда ведут две стрелки) и «Стоки» (сущности, куда ведут две стрелки). Стрелкой считаем связь . Учитываем только связи из цикла! |
|||||||||||
|
|
|
Если в цикле ровно 1 источник (И) и 1 сток (С), есть «прямая» связь И=►С и она имеет тот же смысл*, что и «окольная» связь И→В→...→С, то прямую связь удаляем. *т.е. экземпляр сущности-стока, находимый по «окольной» связи, всегда совпадает с экземпляром, находимым по «прямой» связи |
||||||||||
|
|
|
Если в цикле несколько источников и стоков, то надо проверить, не потеряна ли диагональная связь И И или С С или общий подфакт (ПФ) двух (или более) источников, упоминающий стоки. |
|
|
|
|||||||
|
|
|
Если нет «прямой» связи И→С, то проверить, нельзя ли после удаления какой-нибудь из связей однозначно восстановить ее по «нелегальным» (т.е. обратным, неоднозначным) окольным связям (например В→С восстановить по BИ→D→С) |
||||||||||
NB! При удалении ключевой связи надо проверить в физической модели ключ и проверить, не удалили ли вообще ключ в сущности. |
|||||||||||||
|
|
Сущность A, у которой нет неключевых атрибутов или связей кроме РОВНО 1й множественной обязательной связи c сущностью B сливается с В. Название остается от «множественной» сущности! NB! Возможно, придется изменить имена перенесенных атрибутов! NB! Перепроверить кардинальности перенесенных связей один к одному! |
|||||||||||
Не делается |
если требуется хранить список A. |
||||||||||||
|
|
Превращается в наследование: |
|
Одноименные общие атрибуты переносятся в родителя, одноименные, не являющиеся общими, переименовываются уникально. |
|||||||||
|
|
Превращается в наследование: |
|
||||||||||
Не делается |
если связь подвижная, т.е. в разное время могут быть соединены разные экземпляры А и В.если есть несколько таких параллельных связей, то выбрать одну из них. |
||||||||||||
|
|
«Пустая» сущность С, имеющая РОВНО 2 связи (обе однозначные) превращается в связь. Кардинальность обоих концов надо проверить! NB! Если связь получается «много-ко-многим» (при стандартных связях АС и СВ), то оптимизация «декоративная», т.к. в БД связь опять заменится таблицей. |
|||||||||||
Не делается: если С используется для выбора пары АВ (т.е. у С есть еще связь!). |
|||||||||||||
Как сделать связь обязательной. Означает, что среди А есть «сироты» - те, у которых нет В. Можно либо:
|
Действия перед преобразованием ER-модели в физ. модель. Указать Ключи сущностей, типы данных атрибутов, имена связей много-ко-многим способ реализации наследования, дать разные короткие латинские имена (можно бессмысленные) параллельным связям приравнять коды именам пометить как «доминантные» концы связей 1-1, куда НЕ НУЖНО переносить внешний ключ.
дырка в power designer: рекурсивные связи через наследование не генерируются. Поэтому надо реализовывать наследование (слиянием) вручную.
Действия перед преобразованием физ. модели в БД, дать осмысленные имена внешний ключам (для параллельных связей - обязательно); если не удалось избавиться от циклов в концептуальной модели - удалить дублирующиеся колонки с заменой внешних ключей.
В БД включить для каждой связи каскадное обновление, в таблицах задать для внешних ключей подстановки* мастером создать диалоговые формы, ориентируясь на соответствие формы-ER отредактировать меню по списку ситуаций (NB: создать свою панель) задать обработчики для событий
Аналогия ER-модели – диалоговые формы
атрибут → простое поле однозначная связь → поле со списком многозначная связь → подчиненная форма |
|
Выбор по простому ключу - надо заполнить следующие свойства поля со списком (подстановки):
источник строк - таблица, откуда выбираются данные
присоединенный столбец - № колонки из , откуда выбираются записываемые данные
ширина столбцов - ширина столбцов , показываемых при выборе, от 1го как минимум до присоединенного, через точку с запятой. Ширина невидимых при выборе = 0. Первый из показываемых будет виден в поле после выбора.
число столбцов - количество столбцов из . Нулевые тоже считаются!!!
Подробнее см. Подстановки в Access.doc
Выбор по составному ключу (СК). Методы: использовать формальный ключ. Чтобы показать пользователю смысловой ключ надо использовать несколько полей со списком с одинаковыми колонками хранения, последовательный выбор отдельных элементов ключа. При выборе надо убирать повторяющиеся значения и учитывать уже выбранные элементы. Эти поля надо обновлять перед выбором! Выбор из запроса, «ключ» которого - сцепленные элементы СК. Выбранное пишется в свободное поле и «распаковывается» по элементам СК обработчиком события. В исходной форме дается кнопка «список», открывающая таблицу соответствия. В каждой ее строке добавляется кнопка «перенос», закрывающая эту таблицу и заполняющая элементы СК из выбранной строки.
Реализация элементов ER-модели в реляционных БД. Связи 1-n реализуются переносом ключа с единичной стороны на множественную (внешний ключ). Связи n-n – отдельной таблицей пар.
Любая реализация наследования должна позволять: получить список всех родительских экземпляров и работать отдельно с экземплярами из "детских" таблиц. Есть следующие варианты реализации:
Обозначим: К - ключевые данные Р - родительские данные, Д - детские данные |
|
|
||
Родительская таблица |
|
|
||
|
Таблицы-дети |
|
|
|
|
|
Все данные – в "детских" таблицах. Родительский список получается их слиянием. |
|
|
- |
КРД |
|||
КР |
КД |
Родительские данные – в родительской таблице. "Детские" – в "детских". Связь (1-0) – перенос ключа родителя в "детскую" сторону. Доступ к Р по связи через К. |
◄ |
рекомендуемые варианты |
КР |
КРД |
Родительские данные – в родительской таблице. В "детских" таблицах – детские + родительские (в том числе ключ, обеспечивающий связь). Обеспечить идентичность Р!!! |
|
|
КРД |
- |
Все данные – в родительской таблице ("лишние" атрибуты = Null). Списки "детей" получаются: при взаимоисключающей классификации – по дополнительному признаку "тип строки" и при невзаимоисключающей – по флагам «относится к подклассу 1», «относится к подклассу 2»,... либо по Null полям |
◄ |
|
КРД |
К |
Все данные – в родительской таблице ("лишние" атрибуты = Null). Детские таблицы содержат только ключи строк-детей (для получения "детских" списков). |
|
|
КРД |
КРД |
Все данные и там, и там. Бессмысленно расточительный вариант. |
|
|
Недостаток современных СУБД: Поля, полученные по связи, не могут входить в ключ или внешний ключ. В результате некоторые безызбыточные схемы не могут быть отображены в виде физической схемы.
Реляционные базы являются фактическим стандартом. Основаны на реляционной алгебре (РА), введенной Коддом.
Основные положения РА:
Если дан набор N множеств (доменов) {Di}, то назовем кортежем (записью) элемент декартового произведения U=D1D2…DN, т.е. упорядоченную N-ку значений <x1, x2,…, xN>, где xiDi.
Отношением (таблицей) называется подмножество U. Позицию в кортеже называют полем записи или столбцом таблицы.
В стандарте РА значения в кортеже идентифицируются номером столбца или названием его домена. В реальной базе, разумеется, они имеют имена.
Над таблицами определены следующие операции, которые и образуют реляционную алгебру:
Все теоретико-множественные операции (объединение, пересечение, разность и т.п.)
Селекция. Выбор подмножества записей по данному условию.
Проекция. Множество записей – то же, но множество столбцов – урезано. Поскольку речь идет о множествах, если при выбрасывании столбцов появляются дублирующие записи, то оставляются только уникальные.
Соединение (join) отношений A и B по определенному столбцу (или нескольким). Каждый кортеж имеет все поля из обоих отношений (столбец, по которому проводится соединение – в одном экземпляре). Содержит все возможные сочетания записи из A и записи из B, где в выделенном столбце их значения равны.
В реальных СУБД join расширен: условие – не только равенство одного столбца (равенство нескольких получается и в РА – применением нескольких join-ов), плюс есть «левый join» – когда во множество сочетаний включаются и записи А, которым нет соответствия в В (с пустыми (null) полями B), «правый» – симметрично, и «полный» – объединение левого и правого.
Нормализация баз данных. Кодд ввел понятие нормализации. Оно сводится к простому соображению: одни и те же данные не должны (по возможности…) повторяться в базе многократно. Это плохо из-за избыточности, но самое плохое в этом (но не всегда замечаемое), что обычно существует крайний случай, при котором множество оказывается пустым и эти повторяющиеся данные просто негде записать.
Например, если хранить в одной таблице данные о товаре (наименование, цена), сделке (дата и количество проданного) и клиенте (наименование и расчетный счет), то цена товара будет повторена многократно. А если у вас не было еще ни одной сделки, то вам некуда записать цену товара.
Существуют несколько нормальных форм – на самом деле просто признаков ненормализованной таблицы, – но все они интересны только исторически. Правило нормализации очевидно (соответствует пятой НФ):